Re: [jakartaee-spec-project-leads] Staging repo advice required

[Mark Thomas <markt@xxxxxxxxxx>]

On 03/01/2020 01:45, Bill Shannon wrote:
> I agree with David.  And I support the use of "-rc1" for "release candidate 1"
> and "-m1" for "milestone 1", and so on.  A milestone may be nowhere near done.
> A release candidate is believed to be completely done, pending testing by
> actual users.

Agreed.

My thinking was to do some m1 releases.

Reading the project handbook and the email below am I correct in
thinking that:

1a. a milestone release isn't an official release so I can "just do it"
without any approvals, votes etc?

1b. If the answer to the above question is "No" then does it change if I
am a project lead?

2. I can push these milestones all the way to Maven Central


BTW, I'm not going to "just do it". I do plan to give a heads up of my
intention on the relevant dev lists and give folks a chance to comment
first.

Mark


> 
> David Blevins wrote on 12/21/19 12:24 PM:
>>> On Dec 21, 2019, at 11:32 AM, Mark Thomas <markt@xxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> To make progress converting the JSP API, I need jakarta.* versions of
>>> the dependencies: EL and Servlet. While EL might not be quite ready for
>>> release (I haven't done a careful check that i's are dotted and t's are
>>> crossed) I do believe it is ready enough for JSP to build against.
>>>
>>> Should I deploy EL 4.0.0 to the staging repo as if it were a release
>>> candidate but with the expectation I'll drop the staging repo and
>>> redploy at least once before the actual release (commenting out the part
>>> of the CI script that commits the updated pom.xml)? Or should I do
>>> something else? If so, what?
>>
>> I don't know if the specifics of what extension should be used, but the approved Jakarta EE 9 release plan does allow you to put release candidates or some form of non final builds out to Maven Central.  Something like "4.0.0-rc1", "4.0.0-m1" or some clearly non-final designation.
>>
>> The motivation being basically what you state: good enough to allow us to take more steps and unblock other dependent specs and implementations, but perhaps not perfect enough for a final (which also requires all the spec, TCK and one implementation to be ready for final).
>>
>> Theoretically at some point in the future when we're following our EFSP a little more strictly, Milestone Builds would actually be a requirement leading up to a final:
>>
>>  - https://www.eclipse.org/projects/efsp/#efsp-reviews-progress
>>
>> I think where that puts you is as long as it's clearly not a final release, you have enough flexibility to ask for forgiveness vs permission.  Regular project vote on proposed rc or milestone binaries is fine.  If someone doesn't like the exact extension you choose, we'll iterate and get better.
>>
>> My $0.02 at least :)
>>
>>
>> -David
>>
>> _______________________________________________
>> jakartaee-spec-project-leads mailing list
>> jakartaee-spec-project-leads@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
>>
> _______________________________________________
> jakartaee-spec-project-leads mailing list
> jakartaee-spec-project-leads@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
>