Re: [servlet-dev] Milestone release - primarily for JSP

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

This is not the way we intend milestone release numbering to work.
This introduces another level in the release numbering.  What we want
is qualifiers on the existing release numbers.

So, just like "5.0.0-SNAPSHOT" is a qualifier on the 5.0.0 release
saying that this is just a "day in the life" version of the 5.0.0
work, "5.0.0-M1" would be the first milestone build on the way to
the 5.0.0 release.  "5.0.0-RC1" would be the first release candidate
on the way to 5.0.0.

A release number such as "5.0.0.M1-SNAPSHOT" looks like a "day in
the life" release of what will be the final 5.0.0.M1 release, which
would be a stable release coming after the final 5.0.0 release.  This
takes us down the slippery slope that I warned about previously with
using milestone releases as a way around the process overhead of doing
a full Jakarta EE release.  We don't want milestone releases to look
like final releases.

Maybe this is the key difference between using "-" and "." as a
separator - dash introduces a release qualifier, whereas dot adds
another level to the release numbering hierarchy.

I understand that some of this is open to interpretation, and different
communities might have different conventions for how this should be done,
but for Jakarta EE and EE4J I would strongly recommend that we stick with
three level release numbers with qualifiers to indicate non-final releases.


So, to update your plan, you would change the version number to 5.0.0-SNAPSHOT.
When the milestone release is ready, you would change the version to 5.0.0-m1
in the release job, do the release, and then the release job would change it
back to 5.0.0-SNAPSHOT.  If a second milestone is needed, you would change the
version to 5.0.0-m2 in the release job, do the release, then change back to
5.0.0-SNAPSHOT.

Since non of these are final releases, the release script can't really pick the
version number of the next release.  It can only recognize that you're doing a
non-final non-SNAPSHOT release and switch the version number back to the
appropriate SNAPSHOT version number after doing the release.

You'll definitely want to create a tag for the 5.0.0-m1 release.  A branch might
be needed as part of the release process, but it would be merged back into
master and destroyed once the release is committed.

BTW, I don't have a strong opinion as to whether we should use upper case or
lower case for these qualifiers.  By analogy with -SNAPSHOT, upper case might
be appropriate, although I've seen lots of use of lower case and that's what
I've been using myself.  But it would probably be nice if we all agreed.

(This discussion probably needs to be moved to the project leads list or wider.)


> Hi all,
> 
> JSP needs a Servlet 5 milestone release so it can start its own
> migration to the jakarta.* namespace.
> 
> I've just completed the process of releasing Jakarta EL 4.0.0.M1 (also
> required by JSP) so I'd like to propose I do the same for Servlet.
> 
> I'll need to:
> a) update the version number to 5.0.0.M1-SNAPSHOT;
> b) tweak the CI system to handle incrementing the version number
>    correctly;
> c) generate the 5.0.0.M1 release; and
> d) update the version number to 5.0.0.M2-SNAPSHOT.
> 
> a) and d) will need another committer to approve my PRs.
> b) and c) I should be able to do myself
> 
> The CI system will create a tag and a branch for 5.0.0.M1. I intend to
> delete the branch since i) we won't be doing any development on it and
> ii) we can recreate it from the tag in the unlikely event we need it.
> 
> Thoughts?
> 
> If there aren't any objections I'd like to get started on this towards
> the end of the week.
> 
> Note: There is a discussion on the project leads list whether it should
> be 5.0.0.M1 or 5.0.0-M1. -M1 is the Maven convention although .M1 is
> used by some projects (and is equivalent) and .M1 also requires fewer
> changes to the standard CI jobs to support.
> 
> Mark