-1 I agree with what David wrote here and also think optionality (or whatever other words are used in those cases) helps even for new specs or features to provide flexibility to implementors, e.g. being able to support REST/MVC or the Servlet/JSP/JSF stack just to repeat one example of many. Werner -1 (Tomitribe) We would also be in favor of a resolution that strongly discourages new optional features. The most likely outcome of this resolution would be that the same optional behavior will still occur, just now called profiles instead of features. The EJB spec for example has 3 optional groups. In future specs we can expect these to simply become optional profiles, an inevitable explosion of profiles and no real change in behavior. We do think there is good reason to have some flexibility to implementors, whether it be called an optional feature or optional profile. Optionality (feature or profile) is useful for introducing innovative new ideas that might not initially gain 100% support from all implementations. Optionality (feature or profile) is useful for deprecating old functionality to make room for new implementations. We are completely on the same page that in our current state is there is far too much optional behavior and we do not want to see more without some very good reasons. Rather than ban one form of optional behavior (feature) and leave others open and unchecked (profile), we'd prefer a resolution whereby specification projects must seek approval for any optional behavior (feature or profile) in either a Plan Review or a Progress Review. We think this would create a needed dialog with spec projects, force us to deal with the implications of our desires for no optional behavior and allow us to learn lessons and adjust course. Assuming this resolution passes, a possible amendment could be: RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features or profiles may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications without prior approval via a Plan Review or Progress Review.
Greetings Jakarta EE Specification Committee,
I need your vote to approve the following resolution:
RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications.
This is a seven day ballot, ending on Wednesday, August 4th. Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.
The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Red Hat, Tomitribe, and Primeton), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.
Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated. _______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
