| Re: [jakarta.ee-spec.committee] Notes on TCK maintenance |
Hi Richard,it would be fantastic if you can summarize the discussion into a coherent proposal.Best Regards,Tanja--On Thu, Jul 19, 2018 at 10:48 AM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:You've received a lot of feedback on all of this ... did you want me to try to handle it or would you prefer to do so yourself?On Wed, Jul 18, 2018 at 12:20 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:______________________________Pushing some rough notes on what we need to draft up or I'll forget the details:- TCK major version is released. Say Jakarta EE 9- All vendors work against this "golden master"- Test challenges happen naturally and result in a growing exclude list- "Passing" means you complete the TCK, minus the tests in the exclude list- At the moment the Specification project would like to unexclude, update or add new tests, a maintenance version is released, such as Jakarta EE 9.0.1- TCK and Specification are versioned/patched in lock-step form- These maintenance allow the exclude list to be reset to zero and new tests to be added- Maintenance versions are subject to the same Specification Committee approval processes as major versions- A cadence for the when or how often maintenance versions must be release is not mandated. In practice it may be quarterly (this is for our notes)- A vendor may pass any of the versions, 9.0.x, and claim compatibility- A compatibility page will be maintained to document all passing implementations, sorting the most up-to-date implementations at the top- Maintenance versions, 9.0.x, may not change the goals or add features to the specification- Test challenges happen naturally and result in a growing exclude list to the maintenance version and the process repeats.- "Passing" means you complete the TCK, minus the tests in the exclude list- Test challenge process and exclude list management- Specification projects are responsible for the handling of test challenges- Challenges are handled and discussed openly on the projects xyz list (could be dev or we make a dedicated list)- Additions to the exclude list must pass a super majority vote by the specification project- Tests may not be altered, fixed, patched or added via an exclude list. This requires a maintenance version as detailed aboveAs a side note commentary, if we did release a maintenance version it would be one way to show "speed" and that we are faster than before. Thus, I don't see them as a problem to be avoided, but an opportunity that should be encouraged. I'd recommend framing things up with quarterly as a goal and our timings and approval processes to ensure that remains realistic._________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.com mittee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec. committee
Tanja Obradovic
Jakarta EE Program Manager | Eclipse Foundation, Inc.
+1.613.295.0105 | eclipse.org | Twitter | LinkedIn | YouTube
Eclipse Foundation: The Platform for Open Innovation and Collaboration
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee- spec.committee