Deploy the milestones (and maybe Releasecandidates) at maven central

[laeubi]

The recent discussions about Milestone-Weeks has lead me to think about how Milestonebuilds can better be tested.

I think one real gap is that currently milestones are not published at maven-central, so often at GA they are there and then only we get feedback about things that break (or are still broken e.g. recently a version bump was missing what gets unnoticed until the release).

So my idea would be (if possible) that milestones are published to central as well, maven has even special handling for milestone builds and therefore maven tools understand this concept:

1. if the version has not changed at the milestone build, do nothing (same will happen at release time)
2. if the version has changed, use the version that will be used at release (e.g. 1.2.300) and append -M1/2/3 (probably even RC1/2)

This will require some adjustments for the scripts, but ensures that also maven consumers can test early and often and probably give feedback before the GA. This can even speed up adoption for consumers like Tycho that then probably use the Milestones in their snapshot builds, what the closes the feedback-cycle in some cases much earlier than today, where when an issue is found after the release it takes another three month to reliable test/depend on a bugfix.

WDYT @merks @mickaelistria

[merks]

We do already publish snapshots that anyone can easily consume.

https://repo.eclipse.org/content/repositories/eclipse-snapshots/

The aggregator already supports snapshots versions well.

It's maybe/probably relatively easy to implement "use -M1 instead of -SNAPSHOT". Maybe we don't even have to get fancy and simply use -M1 qualifier for everything; if there already is a x.y.z-M1 published, then there is also already a x.y.z released version published, so we could just reuse the same/current approach of not publishing it if it already exists...

I think Xtext does what you are suggesting:

https://repo1.maven.org/maven2/org/eclipse/xtext/org.eclipse.xtext/

Of course this approach is yet more work of the uncool kind. 😱 Also, I'm not sure people would really test such things; many people prefer that someone else tests things before they consume such things. Also, might it be the case that people end up consuming x.y.z-M1 instead of x.y.(z -1), because it's a never version, such that they are impact by unreleased changes "accidentally"?

[HannesWell]

We do already publish snapshots that anyone can easily consume.

https://repo.eclipse.org/content/repositories/eclipse-snapshots/

That's great.

Personally I often find it odd to publish MX/RCX version on Maven-Central just like 'final' releases, because Maven-Central retains forever and IMHO that's not a need for milestones/Release candidates. Nevertheless Eclipse would not be the first provider of such non 'final' release versions. If we want to provide the Milestones/Release-Candidates as less often updating intermediate/preview version of a release, we could just provide the MX/RCX version the snapshot repo?

Besides that, if we want to make it easier to consumer not yet released versions of Eclipse artifacts, we could consider to deploy the snapshots to the OSSRH snapshot repo instead of the one of eclipse. Then users just have to change the version to snapshot and don't need to know the Eclipse snapshot repo.

[mickaelistria]

Technically, what can be done for M/RC is to push them to a staging respository under oss.sonatype.org Nexus instance and let consumers use this repository until it's replaced by a newer one; but do not release it to Central. As @merks mentioned, it's still additional operational work to do over the current state.

[laeubi]

The problem with a snapshot is that is changes over time also most company policies forbid using unreleased artifacts. Also Tycho can't perform a release if the artifact is not deployed to central.

And as mentioned if nothing is new then of course one would not release a RC / MILESTONE ... also if from Milestone > Release nothing changes there is no immediate need to do a "real" realease, just look at

https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-surefire-plugin

the have had milestone releases from 2018 to 2023 (5 years!), still there are > 70 consumers happily using it ... (Tycho for a long time used M3) The difference is just that one usually pins a dependency to one version in maven (version ranges are bad) so usually the only "risk" is that a MILESTONE might contain preliminary API, so when changing from V1 > V2-M1 > V2-M2> ... > V2 there might be incompatibilities / breakages between each transition, but some deserve to adapt early than having a big bang from V1 > V2