Write release notes and migration guides.

Author: andriyDev

release-content/migration-guides/reader_required_features.md

@@ -0,0 +1,40 @@
+---
+title: The `AssetReader` trait now takes a `ReaderRequiredFeatures` argument.
+pull_requests: []
+---
+
+The `AssetReader::read` method now takes an additional `ReaderRequiredFeatures` argument. If
+previously you had:
+
+```rust
+struct MyAssetReader;
+
+impl AssetReader for MyAssetReader {
+    async fn read<'a>(
+        &'a self,
+        path: &'a Path,
+    ) -> Result<impl Reader + 'a, AssetReaderError> {
+        todo!()
+    }
+
+    // more stuff...
+}
+```
+
+Change this to:
+
+```rust
+struct MyAssetReader;
+
+impl AssetReader for MyAssetReader {
+    async fn read<'a>(
+        &'a self,
+        path: &'a Path,
+        _required_features: ReaderRequiredFeatures,
+    ) -> Result<impl Reader + 'a, AssetReaderError> {
+        todo!()
+    }
+
+    // more stuff...
+}
+```

release-content/migration-guides/readers_impl_async_seek.md

@@ -0,0 +1,53 @@
+---
+title: Implementations of `Reader` now must implement `AsyncSeek`, and `AsyncSeekForward` is deleted.
+pull_requests: []
+---
+
+The `Reader` trait no longer requires implementing `AsyncSeekForward` and instead requires
+implementing `AsyncSeek`. Each reader will have its own unique implementation so implementing this
+will be case specific. The simplest implementation is to simply reject these seeking cases like so:
+
+```rust
+impl AsyncSeek for MyReader {
+    fn poll_seek(
+        self: Pin<&mut Self>,
+        _cx: &mut core::task::Context<'_>,
+        pos: SeekFrom,
+    ) -> Poll<std::io::Result<u64>> {
+        let forward = match pos {
+            SeekFrom::Current(curr) if curr >= 0 => curr as u64,
+            _ => return std::io::Error::new(
+                std::io::ErrorKind::InvalidInput,
+                "invalid seek mode",
+            ),
+        };
+
+        // Do whatever your previous `AsyncSeekForward` implementation did...
+    }
+}
+```
+
+In addition, the `AssetReader` trait now includes a `ReaderRequiredFeatures` argument which can be
+used to return an error early for invalid requests. For example:
+
+```rust
+impl AssetReader for MyAssetReader {
+    async fn read<'a>(
+        &'a self,
+        path: &'a Path,
+        required_features: ReaderRequiredFeatures,
+    ) -> Result<impl Reader, AssetReaderError> {
+        match required_features.seek {
+            SeekKind::Forward => {}
+            SeekKind::AnySeek => return Err(UnsupportedReaderFeature::AnySeek),
+        }
+
+        // Do whatever your previous `AssetReader` implementation did, like...
+        Ok(MyReader)
+    }
+}
+```
+
+Since we now just use the `AsyncSeek` trait, we've deleted the `AsyncSeekForward` trait. Users of
+this trait can migrate by calling the `AsyncSeek::poll_seek` method with
+`SeekFrom::Current(offset)`, or the `AsyncSeekExt::seek` method.

release-content/release-notes/optional_asset_reader_seek.md

@@ -0,0 +1,25 @@
+---
+title: The `AssetReader` trait can now (optionally) support seeking any direction.
+authors: ["@andriyDev"]
+pull_requests: []
+---
+
+In Bevy 0.15, we replaced the `AsyncSeek` super trait on `Reader` with `AsyncSeekForward`. This
+allowed our `Reader` trait to apply to more cases (e.g., it could allow cases like an HTTP request,
+which may not support seeking backwards). However, it also meant that we could no longer use seeking
+fully where it was available.
+
+To resolve this issue, we now allow `AssetLoader`s to provide a `ReaderRequiredFeatures` to the
+`AssetReader`. The `AssetReader` can then choose how to handle those required features. For example,
+it can return an error to indicate that the feature is not supported, or it can choose to use a
+different `Reader` implementation to fallback in order to continue to support the feature.
+
+This allowed us to bring back the "requirement" the `Reader: AsyncSeek`, but with a more relaxed
+policy: the `Reader` may choose to avoid supporting certain features (corresponding to fields in
+`ReaderRequiredFeatures`).
+
+Our general recommendation is that if your `Reader` implementation does not support a feature, make
+your `AssetReader` just return an error for that feature. Usually, an `AssetLoader` can implement a
+fallback itself (e.g., reading all the data into memory and then loading from that), and loaders can
+be selected using `.meta` files (allowing for fine-grained opt-in in these cases). However if there
+is some reasonable implementation you can provide (even if not optimal), feel free to provide one!