[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jakarta.ee-spec] Options for platform-dependent specs
|
We discussed this at the tail end of last week's Specification Committee meeting, sending a recap for a decision on tomorrow's Specification Committee call.
Problem #1: We have a number of specifications that are dependent on the release of the Platform. We have in the past held them until the platform itself is ready for ballot. The question for these specifications: can we find some way to put them up for ballot sooner.
Problem #2: We have a specification (CDI) which we have released sooner, but with the knowledge that none of the "enterprise" tests in the CDI TCK were passed by the compatible implementation. The questions for this specification: can we find a way to ensure those tests are passed, even if later.
In both of the above situations there is some form of dependance on the Platform.
Some thoughts on how we could address the above.
- Option 1: Status quo. We do nothing different. Specifications affected by #1 will just wait till the end as we did for Jakarta EE 8. Specifications affected by #2 (CDI) would just continue as usual, going up for ballot with 30% or so of the TCK unpassed; we would not allow other specifications to do that, however.
- Option 2: "Dependent" Ballots of spec+api. We prepare the materials we have, which in most cases are spec and api jars, and put them up for vote. That vote would indicate the ballot's successful conclusion is dependent on the successful completion of the future Platform ballot. Therefore, when that dependent ballot period ends the materials still cannot be published. We must wait for the Platform ballot to complete. When the Platform ballot goes up, it must include certification requests for every dependent ballot that preceded it.
- Option 3: "Dependent" Ballots of spec + api + interim certification request. We do everything we detailed in Option #2, but with the addition that we need a interim certification request. The goal of the interim certification request is to demonstrate the Platform TCK tests related to this specification can be passed before a ballot is started. The implementation would not need to pass all tests of the Platform TCK, just the ones we deem related. The implementation and TCK could be a snapshot, but with the caveat these binaries need to remain safe and not changed/deleted until the Platform Ballot is cast. As with Option #2 the Platform ballot would contain new and now complete certification requests for each dependent ballot. We would not "update" the old interim certification requests, we would just replace them.
Sending this email to the public list as the private list is not archived and history of decisions and options considered is very important. This year has reminded me any one of us can be gone at any time.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
