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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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