RELEASE-NOTES: note List fix, add more details

RELEASE-NOTES.mkdn

@@ -11,10 +11,14 @@ can build `lilos` and applications. I'm relying on CI to check this and not
 using 1.69 for day-to-day development because it predates Cargo's sparse index
 fix.
 
+### Breaking changes and how to adapt to them
+
 - Time-related public API is now centralized in the `time` module. In earlier
   versions this was split between `time` and `exec` for historical reasons. For
   porting existing programs, look for uses of the `sleep_*`, `with_*`, and
-  `PeriodicGate` APIs; they have moved.
+  `PeriodicGate` APIs; they have moved. I've been careful not to _rename_ any of
+  these APIs, so you should just need to replace the `exec` module with `time`
+  where you see compile errors.
 
 - Renamed `spsc` and `handoff` split handle types: `Push` is now `Pusher`, `Pop`
   is now `Popper`. (Because their old names sounded like what you'd name the
@@ -32,17 +36,45 @@ fix.
     make it harder to grab by accident and easier to spot in code review.)
 
 - Removed operations that were marked as deprecated during the 0.3.x series:
-  `spsc::Push::push`.
+  `spsc::Push::push`. Please use `reserve` instead.
 
 - The `handoff` module is no longer part of the `lilos` crate. It has been
   extracted into a separate `lilos-handoff` crate. If you want it, add that
   crate to your project, and change references from `lilos::handoff` to
   `lilos_handoff`. (It's incredibly useful, but has some gotchas, so it seemed
-  inappropriate in the core API.)
+  inappropriate in the core API.) Chances are pretty good that more "contrib"
+  code like this will appear in a separate crate soon.
+
+
+### Internal bug fixes
+
+- Changes to the internal representation of the timer list will render
+  applications built with this version of `lilos` incompatible with older
+  versions of `lildbg`.
+
+- Fixed yet another soundness issue in `List`, where the `insert_and_wait`
+  operation was linking the `Node` into the `List` eagerly, before being polled.
+  This exposed it to being passed to `forget`, which would leave the list in a
+  corrupt state; once a future is polled, it's known to be pinned and can no
+  longer be forgotten. The good news is, the issues with `List` have all been in
+  slightly different areas, and I think it's rapidly approaching "correct." In
+  practice, it was impossible to trigger this bug unless you've got custom
+  synchronization primitives that use `List` directly, _and_ you do some very
+  strange things involving calling `forget` on futures.
+
+- Removed accidental double-drop of `Waker` in `List`. In `lilos` the `Drop`
+  impl for `Waker` is a no-op, which is how this went unnoticed for this long.
+  But it was still wrong, so, fixed now.
+
+### Cleanups and future-proofing
 
 - The codebase should be ready for the `static_mut_refs` lint in Rust 1.77,
   which will become a hard error in the eagerly-awaited 2024 edition.
 
+- Concrete future types are exposed for a few more operations, in case you need
+  to store them in a struct or something:
+  - `exec::Notify::until` and `exec::Notify::until_racy`
+
 - @helixbass contributed a build of the OS testsuite for STM32F3. While the
   testsuite itself is processor-independent, this will make it easier for people
   to use the testsuite on the popular STM32F3-DISCOVERY board.