Re: [jakartaee-spec-project-leads] Consistent checkboxes for jakartaee/s

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

Hi Tom,

 

My understanding on this is that as a sanity check for the api jar you can run the final TCK against GlassFish 5.1 with the api jar replaced.

 

However for the release it is not necessary to replace the jar in GlassFish to show that GlassFish 5.1 is a compatible implementation. As the latest api jar has no changes to the api signatures GlassFish 5.1 will still pass the TCK w/o an update and that is enough to meet the Compatible Implementation criteria.

 

Steve

 

From: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx <jakartaee-spec-project-leads-bounces@xxxxxxxxxxx> On Behalf Of Tom Jenkinson
Sent: 31 July 2019 13:26
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakartaee-spec-project-leads] Consistent checkboxes for jakartaee/specifications PRs & review notes everyone should know

 

 

 

On Wed, 31 Jul 2019 at 03:57, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

All,

I went through all the Spec PRs and updated them so each has the exact same 9 checkboxes. Some special notes below.

# JAVADOC CHECKBOX

Many of you now have a "PR# 2 JavaDoc" item that may or may not be checked appropriately.  Can you please review?

This is important as some specs have not yet created their Javadoc PR, such as the Jakarta EE Platform spec.  Everyone else has to get that one done first!


# TCK BINARY CHECKBOX

For those of you who have not yet found your TCK and completed that checkbox.  Your link is likely one of these:

 - https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/

If your link references a "latest.zip", that is not the right binary.


# TCK RESULTS

There was a tck results checkbox, it was replaced by the new checkbox "The URL of the compatibility certification request issue:"


# CERTIFICATION REQUEST

The URL of the compatibility certification request issue must be something like these:

 - https://github.com/eclipse-ee4j/mail-spec/issues/1
 - https://github.com/eclipse-ee4j/batch-tck/issues/1
 - https://github.com/eclipse-ee4j/injection-spec/issues/3

You need to use the exact TCK linked in PR, not a snapshot or "latest.zip"

The TCK results must be hosted by the Compatible Implementation, not the Specification Project.  Links to the Specification Project's CI (continuous integration, aka Jenkins job) are not valid.


# COMPATIBLE IMPLEMENTATION

The _index.md in your PR must list the Name and Version of the Compatible Implementation that filed the compatibility certification request.  Acceptable examples:

 - https://github.com/jakartaee/specifications/pull/3/files#diff-d72ca3f01299e61cc5b1fd90c8cc52e1R34
 - https://github.com/jakartaee/specifications/pull/63/files#diff-74c859868fe2d9c9b5fc4558f9839493R28
 - https://github.com/jakartaee/specifications/pull/14/files#diff-207016c01de902da42c71f133c360c1bR33

It is not the name and version of your spec.

A PR cannot be put to vote without at least one Compatible Implementation.  One or more is required.

You cannot use a modified Compatible Implementation such as GlassFish 5.1 with modified API jars.

 

Let's say Glassfish is going to be the CI. I thought we were not meant to release our artifacts from staging until the release review is complete so I am not sure how to say that Glassfish 5.1.0 is compatible with Jakarta Transactions 1.3 without replacing the Jakarta Transactions jar in the glassfish zip. Do you have any suggestions of the expected workflow?

 

Thanks!

 

--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com


_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads