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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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?  Or,
are the Milestone artifacts your "final offer"?  We need
to figure out something that will work for the overall Platform to allow
continued progress.  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

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