Changing release process

Orekit development
1

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?

1 Like
2

Hello!

We can do exactly as you described in your message. I quickly looked and this seems to be the only solution for publishing artifacts to Maven Central.

Bryan

1 Like
3

I took a look at the documentation. It seems that we can use the self-migration process:

image
image600×359 25.4 KB

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?

2 Likes
4

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.

2 Likes