Re: [jakartaee-spec-project-leads] Milestone releases was: Milestone rel

[Mark Thomas <markt@xxxxxxxxxx>]

On 10/01/2020 00:10, Bill Shannon wrote:
> Mark Thomas wrote on 1/9/20 12:21 AM:

<snip/>

>> I do think it is worth clarifying exactly what we want the release job
>> to do (thinking just in terms of outputs, not how we get there). At the
>> moment, given a current version number of 1.0.0-SNAPHOT in master the
>> release job:
>> - creates a 1.0.0 release in the staging repo
>> - creates a 1.0.0 tag
>> - creates a 1.0.0 branch
>> - increments the version to 1.0.1-SNAPSHOT in the 1.0.0 branch
>>
>> I don't understand the last item. I'd expect it to increment the version
>> number in the branch the release was made from. Have I missed something
>> or should I look into trying to change this?
> 
> The intent is that one you've "committed" to the 1.0.0 release, the 1.0.0
> branch is merged back into master and destroyed, and now master is working
> on 1.0.1-SNAPSHOT.  If for some reason you decide to abandon the release,
> maser is still working on 1.0.0-SNAPSHOT.

Ah. That makes sense. Thanks for the clarification. I tend to start from
the view "The tag is immutable, version numbers are cheap and if the
release fails you just move to the next version number". But that isn't
what we are doing here.

>> Also, I think keeping the branch is unnecessary. Can we remove the
>> branch as part of the release job (or not create it in the first place)?
> 
> The manual branch removal is tied to the external and manual verification that
> the release was done properly and is actually what you want.

Got it.

>> Further, I'd like to propose the following additional behaviour if a
>> QUALIFIER is configured for the release job. My proposal is given a
>> current version number of 1.0.0-SNAPHOT in master and a QUALIFIER set to
>> M1 the release job:
>> - creates a 1.0.0-M1 release in the staging repo
>> - creates a 1.0.0-M1 tag
>> - leaves the version number in master unchanged
> 
> Again, I think the intent is that everything related to the release is done
> in a branch, so that if you decide that the release was not done properly you
> can just delete the branch, and if you decide the release *was* done properly
> you would merge the branch into maser and delete the branch.
> 
> Does that make sense?

It does. I'm not entirely convinced that there is a need to for a branch
for a milestone or other qualifier release but deleting it is a single
click in the UI and probably a lot less work than trying to update the
CI script. I'll try things as they are for the next few milestone
releases I'm planning to work on (WebSocket, Servlet and JSP) and see
how things go. I may come back to this list with more questions and/or
suggested changes once I have been through the process a few more times.

Cheers,

Mark