[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
|
As long as we have a clear definition on what a non-functional change is, then this should work.
Scott,
Thanks! I
agree that the javadoc is an extension of the spec document. It actually
*was* the spec document in most cases in Jakarta EE 8.
When we discussed
this on a Spec Committee call, the discussion centered around trusting
and assuming the projects will do the right thing and not introduce any
functional changes in a service release. That is, if we have defined
what a service release is (with the two proposed PRs), then Spec Projects
need to adhere to this requirement of no functional (or behavior) changes
in a service release. And, allow the Spec Projects to deliver service
releases on their own schedule and with no formal ballot as long as a major
or minor release was performed within the last 12 months.
If it is later
determined that a Spec Project violated that requirement, they would immediately
be required to go through a full release cycle for a new major or minor
release.
And, if it's later
determined that Spec Projects in general are violating this requirement,
then we'll have to go back to full release reviews with ballots for all
major, minor, and service releases.
Would this satisfy
your question?
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From:
Scott
Stark <sstark@xxxxxxxxxx>
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
02/18/2021
11:55
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
So a spec team basically needs sign off
from the specification committee on whether a vote can be bypassed. That
still is essentially a lazy consensus vote that needs some initiation to
involve the specification committee because we don't want to have people
outside of the team arguing that spec of api changes were actually made.
Several specs do document behavior in javadocs comments and are essentially
extensions of the spec document.
On Wed, Feb 17, 2021 at 6:57 AM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:
Hi,
I'm confused where we are at in regards to allowing simple Service Releases.
Here are the minutes from when we last discussed this:
- Continue working on
the Release Review requirement for a Service
(Patch) ReleaseChanges
to the EFSP regarding Service Release will be contemplated in the next
rev of the process.
- Open issues to the
EFSP as required
Wayne
to investigate leveraging an “errata” approach to handling no-functionality-changes.
https://github.com/EclipseFdn/EFSP/issues/32
We have several Specifications that would like to do a service release
(x.y.z) in the very near future. These are not considered part of
Jakarta EE 9.1, but we still need to communicate a process to them.
If I go off of this statement from the minutes: Is
a ballot always required? The Specification Committee acts in its best
judgement whether a ballot is needed.
Then, don't we have the liberty to forego a formal ballot for a service
release? And, thus my PRs for updating the JESP and our Operations
Guide are valid until we get further clarification defined at the EFSP
level?
We are already allowing service releases for the TCK without any fanfare.
We've already done a 9.0.1 and 9.0.2 TCK release. Can't we do the
same thing for the Javadoc updates via the APIs? As long as we're
firm on the requirement of no functional changes (and that's spelled out
in the PRs above), then we should be good to go. Right?
Please comment so that I can provide a better answer to the teams looking
to produce service releases. Thanks!
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
