Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] [External] : Re: Procedure for adding service release details to Spec. pages (TCK Service releases for EE 9.1)

The PR is proposed:

Update to provide links for JDK 11 supported TCKs. #371

I did not update the Spec pages that are annexed to the Platform TCK. Kevin, if you'd like me to add those, I'm happy to take care of those though it may make sense for that to be included in the 9.1 release PR. For the moment, this only includes the "stand-alone" TCKs that come from Jakarta EE TCK project (list [1] in my original message).

Happy to get any feedback you may like to offer.

-- Ed

On 4/21/2021 9:59 AM, Ed Bratt wrote:

This was discussed in the Spec. committee meeting. We concluded that it is okay to to do a single PR as follows:

Original TCK line(s) remains as is. Add a sub-bullet that indicates that JDK 11 support is added (rather than JDK 8 and JDK 11). In my example, I'd change it to the following:

  • Jakarta Connectors 2.0 TCK(sig, sha, pub)
    • 2.0.1 TCK add support for JDK 11 (sig, sha, pub)

To Scott Marlow's question about Excludes -- there are already some new excludes in a small number of these TCKs. This was discussed as well. It seemed to be consensus that new excludes should just be added to the "dot, dot next" release. We do not need to create patches for previous versions. To generalize, if there are excludes added, they would always go to the latest version of any TCK release version (i.e. 2.0.0 excludes go into 2.0.1. Additional excludes, even if found in 2.0.0 would go into 2.0.2 (and not be added to 2.0.1+)). We would always encourage implementations to use the latest TCK but if they complete their work with a previous TCK, that is valid -- even if newer versions have already been approved.

Additionally, it was noted that general service release checklist and procedures should be enhanced -- for example a small number of service releases have also made correction changes to other elements so having a written outline for mentors to follow will be beneficial.

For the change with the JDK11 TCK updates described here, I will reply with the PR ID, once it's ready for review.

Cheers,

-- Ed

On 4/21/2021 7:27 AM, Scott Stark wrote:
I thought that challenges had to apply to only the latest TCK. If the 2.0.0 TCK challenge does not also apply to the 2.0.1 release, then theoretically they can certify using that. We cannot be patching arbitrary past TCK versions.

On Wed, Apr 21, 2021 at 8:04 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On 4/19/21 3:03 PM, Ed Bratt wrote:

Hi,

I don't think we finalized how to update the Spec. pages for the service releases needed to coincide with the Jakarta EE 9.1 release. If we have and I'm just not recalling, please point me at the details so I can follow the designated procedure.

All the component TCKs that are produced from Jakarta EE TCK project (see [1] below) are updated to include instructions and signature test files for JDK 11. The Spec. pages for each of these need to be updated to add link to the updated service release TCK.

I think a reasonable mechanism would be to simply add the service release TCK link as a second line

e.g. -- for Connector Spec.

  • Jakarta Connectors 2.0 TCK(sig, sha, pub)
    • 2.0.1 TCK for JDK 8 or JDK 11 (sig, sha, pub)

I have a related question, if we get a TCK challenge to exclude (#1) a test in the Connectors 2.0.1 TCK and a challenge to also exclude (#2) a test in the Connectors 2.0.0 TCK, what would we do?

1.  Release Connectors 2.0.2 TCK with both excludes #1 + #2 (both generated from the Platform TCK 9.1.x branch).
2.  Release Connectors 2.0.2 TCK with both excludes #1 (generated from the Platform TCK 9.1.x branch) and release Connectors 2.0.3 TCK with excludes #2 (generated from the Platform TCK 9.0.x branch).

I regret that I cannot make the meeting today.

Scott


(each of sig, sha, and pub would be links to the final TCK location/details.) (We could add JDK 8 to the original line, just to clarify for future readers if we think that's helpful.) I would avoid just replacing the links to the original TCK since those remain valid and we don't know if anyone is currently working with those.

I don't think this requires distribution of mentors if we agree with a template for the proposed change but a PR approver might be useful to avoid stupid errors. Hopefully, with whatever we finalize, this might be feasible in a single PR that updates all the Specs that are impacted [1] in this way.

Seems like this needs, at the least a general thumbs-up from the committee. (Or, if this is already decided, just correct me so we can follow the correct path.)

-- Ed

[1] -- Stand-alone specification TCKs that are produced by Jakarta EE Platform TCK project:

  • Component Spec. TCK service releases (If not already assigned, the remaining could be handled in a single PR):
    • Annotations   
    • Authentication
    • Authorization
    • Concurrency
    • Connector
    • _expression_ Language
    • JSONB
    • JSONP (Already assigned mentor)
    • Messaging
    • Persistence
    • RESTful Web Services
    • Security
    • Server Faces
    • Server Pages
    • Servlet
    • SOAP with Attachments (Already assigned mentor)
    • Standard Tag Library
    • Transactions
    • WebSocket
    • XML Web Services (Already assigned mentor)
[2] Following will need to be adjusted to point to the Jakarta EE 9.1 TCK (along with Platform and Web Profile). My recommendation would be that these be updated in the same PR that updates the Platform and Web Profile details using the same template as is agreed upon, with the previous list.
    • Enterprise Beans
    • Enterprise Web Services
    • Interceptors
    • Managed Beans
    • Web Services Metadata


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!GqivPVa7Brio!MjQWhBvgcjoZ9VkHy4f80Ci1rdt_ani7chJX-OqDQG6ga2HUQcv2Rs2rD4t4-dQ$

Back to the top