Cuts 2.5.0 and closes Tier 12. Merge this, and the annotated tag goes on the merge commit.
What ships
- Android, run in release with the shrinker on, or the JVM artifact declared to be the Android one (M74)
- A footprint row computed from a resolved classpath, and an SBOM per release (M75)
- A weekly run against the newest Qdrant, so a release is noticed by CI rather than by a person (M76)
- A benchmark baseline, so a regression is visible without opening two artifacts (M77)
- Java called from a source set rather than described in a paragraph (M78)
- An API reference per released version (M79)
Why it is a minor
Most of this tier changes what the build checks and what the release publishes rather than what the
library exposes. Nothing here deprecates anything, and no signature moves.
M74 is the one that can add surface. If it concludes with an androidTarget() then there is a new
coordinate on Maven Central, which is additive and belongs in Added rather than in Internal, and the
2.x promise now covers a target it did not, which STABILITY.md has to state rather than imply. If it
concludes that the JVM artifact is the Android artifact, that is a paragraph and a keep-rules file and
the published set is unchanged.
Before tagging
Reconcile git log v2.4.0..HEAD against [Unreleased]. This has found undocumented merges on every
release so far, so it is the expected outcome rather than the exception.
This is the first release where the pre-tag list should be shorter than the one before it. M75 and M76
exist to take the footprint row and the compatibility table off it, and M77 does the same for the
benchmark numbers. Check that they actually did, one at a time: the first release after an automation is
where it is discovered that the automation runs on a schedule nobody has waited for yet.
M79 changes where the API docs badge points. Follow it after the release rather than before, because a
badge pointing at a version the site does not carry yet is the one failure this milestone introduces.
The product page is the third copy of these facts
After the README and the POM there is the page on nacodestudios.it, and it holds the version, the
install snippet, the module count, the platform list and the highlights. It is a document in Firestore
rather than a file in this repository, so a release that goes perfectly green leaves it exactly as it
was, and nothing anywhere reports the difference. If M74 added a platform, this is the copy that will go
on not mentioning it.
Do it in the same sitting as the tag and read the document back afterwards.
Exit criterion: the tag is on Maven Central with provenance and an SBOM, the GitHub Release renders the
changelog entry and carries the CLI binaries, the API reference site carries 2.5.0 and the badge points
at it, the product page states the version that was just published, and every Tier 12 item on the board
reads Shipped with 2.5.0 in Target version.
Cuts
2.5.0and closes Tier 12. Merge this, and the annotated tag goes on the merge commit.What ships
Why it is a minor
Most of this tier changes what the build checks and what the release publishes rather than what the
library exposes. Nothing here deprecates anything, and no signature moves.
M74 is the one that can add surface. If it concludes with an
androidTarget()then there is a newcoordinate on Maven Central, which is additive and belongs in
Addedrather than inInternal, and the2.xpromise now covers a target it did not, whichSTABILITY.mdhas to state rather than imply. If itconcludes that the JVM artifact is the Android artifact, that is a paragraph and a keep-rules file and
the published set is unchanged.
Before tagging
Reconcile
git log v2.4.0..HEADagainst[Unreleased]. This has found undocumented merges on everyrelease so far, so it is the expected outcome rather than the exception.
This is the first release where the pre-tag list should be shorter than the one before it. M75 and M76
exist to take the footprint row and the compatibility table off it, and M77 does the same for the
benchmark numbers. Check that they actually did, one at a time: the first release after an automation is
where it is discovered that the automation runs on a schedule nobody has waited for yet.
M79 changes where the API docs badge points. Follow it after the release rather than before, because a
badge pointing at a version the site does not carry yet is the one failure this milestone introduces.
The product page is the third copy of these facts
After the README and the POM there is the page on nacodestudios.it, and it holds the version, the
install snippet, the module count, the platform list and the highlights. It is a document in Firestore
rather than a file in this repository, so a release that goes perfectly green leaves it exactly as it
was, and nothing anywhere reports the difference. If M74 added a platform, this is the copy that will go
on not mentioning it.
Do it in the same sitting as the tag and read the document back afterwards.
Exit criterion: the tag is on Maven Central with provenance and an SBOM, the GitHub Release renders the
changelog entry and carries the CLI binaries, the API reference site carries
2.5.0and the badge pointsat it, the product page states the version that was just published, and every Tier 12 item on the board
reads Shipped with
2.5.0in Target version.