Re: [jakartaee-platform-dev] Release Candidate APIs vs Milestone APIs

[Mark Thomas <markt@xxxxxxxxxx>]

I disagree with this view.

Progress requires a JAR with the javax -> jakarta renaming believed to
be complete. The M1 releases for EL, WebSocket and Servlet provide this
and JSP is close to providing an M1 as well.

As per the Eclipse Project Handbook, an RC is a "feature complete"
milestone. Some specs, Servlet included, are discussing minor API
changes. Until that decision is resolved, milestone releases are
appropriate.

As per the Eclipse Project Handbook, an RC is expected to go through a
release review with the potential of becoming the final release. Given
the requirements for TCKs and compatible implementations, I don't see
any of the projects I am involved in being in a position to create an RC
for several months.

Downstream users don't need to wait for an RC to make progress. They can
make significant progress with a milestone build and pick up any changes
in subsequent releases as they go. This has the added benefit that they
can provide early feedback on any issues they find with the milestone
releases.

My understanding of the "RC available" checkbox was to track when
something was available that was considered suitable by the project for
downstream users to work with. I agree that Milestone builds might not
meet this definition but I also think that it is perfectly possible for
a build to meet this definition without meeting all of the requirements
for an RC build.

Rather than "RC available" I suggest we make this check box "Milestone
build with javax -> jakarta renaming complete available". It probably
makes sense to track "RC available" as a separate entry.

Mark


On 22/01/2020 14:28, Kevin Sutter wrote:
> Hi,
> I've been noticing several Projects declaring a Milestone API driver as
> a Release Candidate in the checklists.  A Milestone driver is not
> sufficient for this requirement.  We need a Release Candidate driver.
>  We discussed this at last week's Platform Call (Jan 15), but I was
> negligent on sending out a note.  My apologies.
> 
> This first came up with theWeb Socket effort
> <https://github.com/eclipse-ee4j/websocket-api/issues/322>.  You'll
> notice that at first I was okay with accepting Milestone builds as
> Release Candidates.  But, on the call, I was educated on the difference
> expectations between the two types of builds.  With a Milestone build,
> it's a step towards a Release.  Each Project could define their own
> Milestones and associated builds and content.  Nobody knows if these are
> complete enough for public consumption -- unless you are intimate with
> the Project.  With a Release Candidate build, the Project has publicly
> declared that they are complete enough for public consumption, and that
> sufficient progress is being made towards the final Release.
> 
> https://github.com/orgs/eclipse-ee4j/projects/17#column-7346435
> 
> It's great that we're getting several Projects with Milestone builds of
> their APIs -- especially all of the "web container" APIs.  But, we
> really need to push towards Release Candidate builds so that everyone
> can start using them -- not only within Jakarta EE, but also tools that
> are being developed for Jakarta EE.  Thanks for your cooperation!
> 
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Jakarta EE architect @ IBM
> e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)    
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
> 
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>