If we had items to vote on I would say yes. It seems that there is at least some desire to counter the current proposed resolution.
Scott,
We decided at
the Spec Committee that we would start the conversation on the private
email first -- to ensure that we have a consistent, agreed-to, defined
approach before sending it to a wider audience. Based on these email
discussions, I'm not sure we're at that point yet. I know we don't
need 100% consensus, but I think it would be good to ensure that we have
a super-majority approval on the direction. Should we take a quick
straw poll of the Spec Committee members? If we have that super-majority,
then we could go ahead with the wider audience. If not, then maybe
we need to iron things out further via email and/or next week's meeting?
---------------------------------------------------
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:
06/17/2021
12:43
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating
Optional aspects of Specifications
Sent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
Also, this is on the private list. I
was going to point to the email for some of our project developers, but
found that it was inaccessible by them (and somehow me as well) when trying
to access https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
On Jun 16, 2021 at 1:59:07 PM, Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:
On our Specification
Committee call today, we discussed a proposed Resolution (prepared by Dan
and Paul) about eliminating the use of Optional features in Jakarta EE
Specifications. We decided that we should discuss the Resolution
via the private mailing list for the next seven days (max). At that
time, hopefully enough input would produce a version of the Resolution
to post to a wider audience (Spec Project Leads and/or public Spec Committee
mailing lists). Again, hopefully, we would get enough input from
these two mailings to allow for a ballot on the Resolution at our next
Spec Committee meeting on the 30th.
First, for background, if you are not familiar with the back story for
this Resolution, please review this document:
https://docs.google.com/document/d/1O5MnbQRn8RWkM4BpJth9VqGfhKLBZfFzK_fpIyZ_2vw/edit
(BTW, before we externalize that document to the Spec Project Leads and/or
public Spec Committee mailing list, we should resolve any outstanding comments...
Dan,I will leave you in charge of that activity.)
The proposed resolution is just a slightly re-worded version of option
#1 in the referenced document.- DRAFT RESOLUTION: To
eliminate marking any Jakarta EE Specification feature as optional in some
future release of each Jakarta EE Working Group Specification, including
and possibly starting with the Jakarta EE Platform Specification Release
10. All remaining features would be required.
- Clarifying text to
the proceeding resolution: The process would be to mark all optional features
in the current release as “Deprecated” in a new Minor release (Release
9.2), and in a subsequent Major release (not necessarily the very next
Major release) eliminate the Deprecated feature completely from the Jakarta
EE Platform Specification. Eliminating these Deprecated features is not
retroactive to earlier released specifications, which will continue to
exist. As implied, “Deprecated” will be defined as a way of marking a
feature as on the path to complete elimination from some future release,
and it indicates to the public “this feature is going away”. This
two-step process provides a formal communication mechanism within the specification
itself for the Working Group to signal to the community that a feature
will definitely be removed from a future release. The intent is to mark
current features marked as “Optional” as “Deprecated”, but in the future
even “Required” features could be marked as “Deprecated” should the
Working Group decide to prune little used features from the platform. This
two-step process will take longer but will also give consumers of the platform
a longer runway to plan for and deal with the elimination of the feature
should they wish to consume that future platform release.
Comments and suggestions are welcome! 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
