The current (long) release process we use for Orekit will need to be changed soon, at least for some steps. We currently use the legacy OSSRH system set up by Sonatype, who manages maven central. This legacy system will reach end of life on June 30 and will be replaced by central portal. We have already been notified several times about that and are clearly late to migrate.
The differences between the two systems are explained here. After a first quick read of this page and some linked pages, I think this will mainly require all release managers to register authentication tokens that could be saved in their $HOME/.m2/settings.xml file, and to change the maven plugin we use to push artifacts to the central portal.
It seems we can still have a time slot to vote for the release, if we select the pushing type to USER_MANAGED (which is the default) instead of AUTOMATIC. When the artifacts are in this staging phase, we can select to drop it or publish it depending of the vote results.
This change is mandatory, legacy OSSRH will be shut down soon.
How do you think we manage the transition?
In order to share the knowledge gained during the migration and the new publication process, it may be useful to carry out this migration as part of a videoconference between the relevant release managers (I am not a release manager, but I am interested in following the process). What do you think?
Yes, it is a good idea.
We should all read the migration process before and agree on what to do, i.e. look at the plugins and create accounts and authentication tokens.
As it seemed difficult to find a time slot that suited everyone, Luc and I migrated the namespace from the old Sonatype portal to the new one (Legacy OSSRH => Central Portal).
Future artifacts can therefore be pushed to the new portal, but no longer to the old one.
However, there is still work to be done:
Add environment variables related to the new Sonatype token in the CI/CD environment.
In addition, Luc showed me that the new portal supports snapshots (the corresponding feature must be enabled). If this is confirmed, we could use the new portal to publish both official releases and snapshots. In this case, our Nexus instance would become unnecessary (provided that the Hipparchus project makes the same choice upstream).
If so, we will still need to consider how to securely implement cryptographic signatures for our packages.
I have started updating the release guide and setting up a release.sh script.
This scripts attempts to perform many steps automatically, asking just a few questions
to users and asking for confirmation before each commit or critical action.
It is not production ready yet, but I would like to have people look at it. It is in the issue-1760 branch (look at at scripts/release.sh and src/site/markdown/release-guide.md).
I would really like to have this script manage all steps, up to creating the voting post on forum (I guess there is an API in discourse for this). Even if the first version of the script does not achieve this, I think it already simplifies a lot the release process, it could probably be used right now.
Streamlining and making the release process reproducible by automating it is highly desirable.
To meet current expectations for supply chain security, the CI/CD process should sign the artifacts generated (whether releases or snapshots). The same artifacts should also be pushed to the Maven Central Portal and our Nexus instance.
