| Re: [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releases |
|
Thank you, Ed, for bringing this up on the committee! I shared my following thoughts:
One issue with alternate is that the tests might make into future release. A further clean up needs to be performed before another minor/major release. We need to track this. I am not sure whether it is necessary to introduce this approach as an implementation can choose which service release they certify. If an implementation certifies against a previous tck, they can continue to do so. Also, as mentioned before on the mailing list, I think we should have more freedom to update tests before platform or web profile releases since they will lock down which service release, they will pull in. We can fix the tcks on a particular service release and then package with platform or web profile release. Any runtime that certifies against individul specs instead web profile or platform, it can choose a particular version.
I also added to the PR as a comment.
Thanks
Emily ================ Emily Jiang Java Champion STSM, Jakarta and MicroProfile Architect
@IBM
Liberty
Cloud Native Architect & Advocate
LinkedIn: https://www.linkedin.com/in/emilyfhjiang/
IBM United Kingdom Limited
Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 06 July 2022 19:33 To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Subject: [EXTERNAL] [jakarta.ee-spec.committee] Comments regarding allowing Alternate tests in TCK patch-releases
This Message Is From an External Sender
This message came from outside your organization.
Hi, Just being overly diligent -- The PR discussed at the last Spec. committee meeting considers adding text allowing Alternate tests in specification patch releases. There are now a couple of proposals to describe this. One in the original, and now one offered by me, in a
comment on the PR. As a committee, we should be sure to consider first, if we are in favor of adding Alternate tests to specification patch releases. If so, then how we will describe this as part of the JESP. If we proceed, we should be prepared to adopt text that we are comfortable with, that suitably describes, limits, etc. their use. I'm not sure everyone on the committee is subscribed to the jakarta.ee repository -- I hope you all are -- and this message is simply added noise about this proposal. This is potentially significant enough that I feel a record of this be kept in the spec.committee list. Personally, I am happy to endorse Alternate tests. We occasionally used them previously but they were not used frequently. In later releases, it was much more common to simply exclude tests that were insufficient when the specification version was released. I would like to ensure:
On a historical note, it is my recollection, we did not include Alternate tests in the original JESP simply because there was no need for them, for the first set of Jakarta tests. We simply elected not to take the time, nor expend the effort needed, to describe
and agree on this, as a feature of the JESP. It seems as if the time has come to consider bringing this feature into the JESP. -- Ed
Unless otherwise stated above:
IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU |