Well, it seems the same thing that happened to Hipparchus 4.0 also happened to Orekit 13.0: the staging repository at SonaType disappeared before the vote was completed.
I have sent a message to support at SonaType to try to understand. I think there is an automatic purge (at least it is how I understand this page), but having the repositories disappearing in just a few days and even before the vote has enough time to complete is a big problem.
I see only two ways to work around this:
either we reduce the vote duration to a very short time (but we still need 3 votes)
or I just give you my words that if the repository disappears at SonaType, I will recreate it and upload it again starting from the same commit
The first solution could work and what would be released would be the files PMC really voted on, but we may miss some important final checks (like the one Evan just did)
The second solution is a matter of trust: people have to trust just me to do the right thing
The namespaces you have registered (org.hipparchus and org.orekit) belong to legacy OSSRH.
We have implemented an active cleanup process for OSSRH due to a recent incident when a
large number of staging repositories caused the service to become unavailable. With this new
cleanup policy:
for staging repositories in an open state, there is a period of 8 hours from the last update in
which you can upload artifacts and close the repository.
for staging repositories in closed state, there is a period of 2 days from the last update in which
you can release or drop the repository.
After these times the repositories are deleted. For the repositories that have been release the
delete is immediate.
I understand your frustration, and we cannot make any exceptions to the rule without risking
another incident. The best option you have going forward is to migrate these namespaces to
Central Portal - that's where the 90 days limit applies.
I will take a look at the Central Portal procedure, but fear we cannot do that in the blink of an eye, so I guess for 13.0 we will have to live with either a less than 2 days vote period, considering we have already voted for RC1, or we keep the vote to 5 days and I will need to upload the binaries twice, once before the vote (and they will remain only for 2 days), and once after the vote, if you trust me.
It seems to me that there are three distinct problems:
The urgent vote for the release of version 13
OK, I just voted for the release
The evolution of the Sonatype repository and the artifact publication process, as well as the reduction of the artifact retention period
Like you, I guess that taking these points into account requires reflection and an adaptation effort that cannot be achieved in the blink of an eye.
The Orekit and Hipparchus release process
Why is it so important to publish the artifacts on the Sonatype portal before the PMC vote?
The CI/CD pipeline publishes the artifacts to our Nexus instance. Of course, the artifacts are not accompanied by a cryptographic signature. But can’t a release manager download these artifacts to their workstation, sign them without rebuild them, and push their GnuPG signature file to our Nexus instance?