| [jakarta.ee-spec.committee] Jakarta EE Versioning, Change, and Deprecation Process Feedback |
|
Hi all, Apologies for the delay in following up on this. From the previous Spec Committee meeting we had one outstanding feedback item on the proposed versioning, change, and deprecation process from Nathan Rauh. --- Transitioning a feature from optional to mandatory is fine for a minor version change because it does not break end users. However, transitioning a feature from mandatory to optional ought
to require a major (not minor) version change because it is a breaking change when the vendor decides to stop providing the now-optional feature. --- This is a comment about the versioning strategy for Component Specification features, highlighting the proposed guidance for what constitutes a minor release: --- Major version change - removal of an optional or mandatory feature Minor version change – new features (mandatory or optional), or the transition of an existing mandatory feature to an optional one (or vice versa). Patch version change – bug fixes to existing features. --- We didn’t get very far into discussing this, though I think the initial reaction was in agreement? While I think it’s valid that the introduction of a
new optional feature can be done within a minor version, transitioning an existing mandatory feature into becoming an optional one can seem a strong change for a minor release since it would essentially allow an implementation to just drop it. That being said, I think the reason I originally worded it like this was because it isn’t actually a breaking change from the Specification perspective – nothing has been removed. If an implementation
elects to simply drop support for the optional part of the spec without any deprecation of its own that’s their prerogative.
Do we want to attempt to “control” this by restricting this kind of change to a major release? Or do we feel like allowing it within a minor release is acceptable if we tighten up the rules a
bit (e.g. mandating that it follow the original pruning strategy of being documented as “marked for optional” for at least one minor or major release)? Last week, there were also some new comments added to the document and the Platform dev mailing list from Jan Westerkamp and Lenny Primak:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg04241.html I’ve provided clarifications to the comments on the document, but please provide your own input if you disagree with my reasonings.
|
