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

[Mark Thomas <markt@xxxxxxxxxx>]

On 28/01/2020 23:09, Kevin Sutter wrote:
> Hi Mark and others,
> Any additional thoughts or suggestions for this hurdle?  The Web
> Container projects are all making great progress towards Jakarta EE 9,
> but we're stuck with Milestone artifacts instead of RC artifacts in
> Maven.  Since we are only asking for the API jar files to be RC
> candidates and not the Specs and TCKs, is that more palatable and doable
> in the near term?

My concern remains that the RC that is being asked for is inconsistent
with the definition of RC in the Eclipse Foundation Project Handbook.

>  Or, are the Milestone artifacts your "final offer"?

I do think the M1 releases from EL, WebSocket, Servlet and JSP are
sufficient to meet requirements intended to be met by the RC being
requested.

The M1 releases are what is available now. RC releases will take time.
There are limited resources available to produce them and a significant
amount of other work both inside Eclipse (primarily TCKs and getting the
JSP and Servlet spec docs into shape) and outside requiring the same
limited resources.

EL is very close to being able to produce an RC. I just need to reply to
the JPMS name thread on the spec leads list. An RC for EL could be
available as early as tomorrow.

The other API JARs aren't too far behind but, unlike EL, I'm not aware
of any progress on the TCK front. I'm reluctant to class anything as
feature complete until I've seen a successful TCK run with the updated
API. Further, any progress on the other projects is dependent on timely
review of PRs. Servlet is OK in this regard. WebSocket and JSP are
rather variable and can often take a week or more.

Of course, none of this stops any other project committer who is less
concerned about the definition of an RC creating an RC. The CI builds
are in place to create RCs and milestones on demand. Actually, that
might not be true at the moment. The projects may need updating to the
1.0.6 parent POM to pick up the repository changes.

>  We need to figure out something that will work for the overall Platform
> to allow continued progress.  Thanks!

I'll repeat my previous suggestion to avoid the RC label and simply ask
projects to provide an interim release (M or RC as appropriate) that has
completed the javax -> jakarta rename and is considered suitable for
downstream projects to base development on.

Mark


> 
> ---------------------------------------------------
> 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-bounces@xxxxxxxxxxx wrote on 01/23/2020 08:56:46:
> 
>> From: "Kevin Sutter" <sutter@xxxxxxxxxx>
>> To: jakartaee-platform developer discussions <jakartaee-platform-
>> dev@xxxxxxxxxxx>
>> Date: 01/23/2020 08:57
>> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Release Candidate
>> APIs vs Milestone APIs
>> Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>> 
>> Mark,
>> The request for the RC is for the API only, not the Spec, not the
>> TCK, and not the Compatible Implementation.  Just the API.
>> 
>> The problem with only requiring a Milestone driver is that every 
>> project has a different definition of a Milestone driver.  One
>> Project may have a large number of APIs with multiple packages that
>> need to be migrated to jakarta.  They may define M1 as completing
>> package javax.A, and M2 could be javax.B, etc.  Prospective users of
>> these Milestone drivers would have to know exactly what each 
>> Milestone driver contained to know whether they are usable for their
>> development.  An RC driver would indicate that all packages have
>> been migrated to jakarta and it's useable by anyone.
>> 
>> As I mentioned in one of your Issues, if you have a Milestone driver
>> that is complete to use by other projects, then why couldn't the 
>> next step of creating an RC for that API jar be performed?  The RC
>> for the API indicates that the API is usable by external projects.  
>> There are bound to be additional updates as more and more teams 
>> start to use them.  That's why we want to make them available as
>> soon as possible.
>> 
>> Concerning your comment about possibly changing the Servlet APIs...
>> Even minor updates to the APIs will require a full Plan Review for
>> those type of changes.  The Jakarta EE 9 Plan only covers the javax
>> -> jakarta namechange.  Any additional work by the APIs would
>> require a separate Plan.  And, the Plan Review identified Feb 1 as
>> the deadline for identifying these potential changes and proposing a
>> Plan to the Spec Committee.  At this point, only EJB and JAF have
>> been identified as requiring a separate Plan Review.  So, as a heads
>> up, if the Servlet team is considering API changes, you would need
>> to start moving on this Plan Review process.  Thanks!
>> 
>> ---------------------------------------------------
>> 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
>> 
>> 
>> 
>> From:        Mark Thomas <markt@xxxxxxxxxx>
>> To:        jakartaee-platform-dev@xxxxxxxxxxx
>> Date:        01/23/2020 02:47
>> Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Release
>> Candidate APIs vs Milestone        APIs
>> Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx
>> 
>> 
>> 
>> 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
>> > 
>> 
>> _______________________________________________
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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
>