Prepare release notes for V9.4.0

[timj]

v9.4.0 seems reasonable.

• Blocked on DM-55992: Fix SEGV when failing to make SplineMap into a SIP WCS #73
• Blocked on Out-of-Starlink build support including running Fortran tests and basic CI #37 (although I could be convinced to defer)
• Still need to convert the approved release notes to latex for the PDF docs

From Claude:

Summarize the changes made since V9.3.1 in ast.news and bump version.number to 9.4.0. The minor version is incremented because enforcing the documented Mapping immutability rule in every class can cause code that previously succeeded to report AST__IMMUT.

The new entries are grouped into behaviour changes, new features, bug fixes and testing/build changes. Related defect fixes are collected into a single entry per class, with nested lists for the FitsChan and KeyMap fixes, so that the volume of individual fixes in this release does not swamp the reader.

Generated with AI

Co-Authored-By: SLAC AI

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.41%. Comparing base (cec0f54) to head (83435a3).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #74   +/-   ##
=======================================
  Coverage   61.41%   61.41%           
=======================================
  Files          83       83           
  Lines       96474    96474           
  Branches    30586    30586           
=======================================
  Hits        59249    59249           
  Misses      21067    21067           
  Partials    16158    16158           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[embray]

I'm glad you are thinking about making a release because I had it on my todo list to start asking about the same. libasdf-gwcs now depends on my fork of AST containing fixes that aren't upstream yet, and is statically linked in since a "normal" AST install as a shared library can't work yet anyways.

For my purposes I would really need

• Out-of-Starlink build support including running Fortran tests and basic CI #37 (as you already mentioned)
• A PR I haven't opened yet for adding support for another transform to YamlChan--I need to finish that.
• Miscellaneous YamlChan bug fixes and test coverage #66
• yamlchan: Add libfyaml support as an alternative to libyaml #67 (ideally, though not strictly required)

I could defer on:

• Experimental optional vectorization for SphMap, PolyMap and MatrixMap #51 though it would be good to have, and seems stalled.

That said, you were also talking on #37 about automated releases which is good, so maybe you are thinking of making a few more frequent? May fork/static lib approach is working fine for now so I don't feel the need to rush you on anything that isn't considered ready.

With AST now building as an independent library it will also be easier to package for conda and homebrew if you haven't already done that. That would be really helpful for users, I think.

[timj]

@embray thanks for the feedback. We already have conda-forge builds. Not homebrew. I am reminded that cmake install hasn't been tested at all but homebrew could use configure.

If I can solve the PDF problem (either by making it separately and uploading it or by writing a python prolat replacement) then I think we can pretty quickly turn around new releases as uploads to GitHub from within an action based on a tag. The ast.news stuff makes it a bit tricky to automatically add release notes. If we get in that position then I would have no objection to rapid releasing of features. I need to get the SEGV fix out for Rubin and I will try to use a more explicit semver model for version numbers. The one other wrinkle is that we have to hard code the new version into the source tree before applying the git tag but we can have a release check that checks that the version and the tag agree.

[embray]

The one other wrinkle is that we have to hard code the new version into the source tree before applying the git tag but we can have a release check that checks that the version and the tag agree

bumpver is pretty good for that. I also put a tag/version string sanity check in my release workflow: https://github.com/asdf-format/libasdf/blob/56d24aa11b3013c362a485b25c2f51db35622d0e/.github/workflows/release.yml#L101