Update Service Release template per experiments with JAF and Mail

[kwsutter]

Signed-off-by: Kevin Sutter kwsutter@gmail.com

Updating the Service Release template per the discussions with Lukas on JAF and Mail. I think I caught everything, but take a look. If we get this good, then we can move onto the other templates.

Also, is there a way to select which PR template to use when creating a PR (similar to selecting a template when creating an Issue)? We should do that.

[netlify]

Deploy preview for jakartaee-specifications ready!

Built with commit 651e398

https://deploy-preview-345--jakartaee-specifications.netlify.app

[lukasj]

I think I caught everything

there is one more thing in the XML binding spec and that is updating the spec document (see #340 (comment)). The question here is the form of the document revision - would probably make sense to capture the pattern to use there in one of the list items

Also, is there a way to select which PR template to use when creating a PR (similar to selecting a template when creating an Issue)? We should do that.

I think it should be enough to put templates into <root>/.github/ISSUE_TEMPLATE/ folder (but check docs)

[ivargrimstad]

I think it should be enough to put templates into <root>/.github/ISSUE_TEMPLATE/ folder (but check docs)

Yes, I'll do that as soon as we are good with the updates.

[ivargrimstad]

I think I caught everything

there is one more thing in the XML binding spec and that is updating the spec document (see #340 (comment)). The question here is the form of the document revision - would probably make sense to capture the pattern to use there in one of the list items

I think the versioning of spec documents is something we need to bring up in the spec committee. We should consider treating the document the same way as the other artifacts. Something like:

• The specification itself has a two-digit version number (X.Y)

• All the artifacts have a three-digit version number (x.y.z)

• Jakarta Wombat X.Y

  • jakarta-wombat-spec-x.y.x.pdf
  • jakarta-wombat-spec-x.y.z.html
  • jakarta-wombat:jakarta-wombat-api:z.y.z
  • jakarta-wombat:jakarta-wombat-javadoc:x.y.z
  • jakarta-wombat-tck-x.y.z.zip

[ivargrimstad]

Shouldn't we allow teams to release the API-jar as well if the JavaDoc is updated? It's part of the same source and CI jobs and is staged along with the JavaDoc It feels like extra work to figure out how to only release a couple of the staged artifacts to Maven Central.

[lukasj]

I think the versioning of spec documents is something we need to bring up in the spec committee.

I recall having a conversation with Bill on this topic long time ago and to make it short - now I've found: https://eclipse-ee4j.github.io/jakartaee-platform/Versioning:

For a spec of version X.Y, the spec document will be version “X.Y” for the initial release or “X.Y Rev L”, where “L” is a letter nominally starting with “a” and incrementing as more errata are approved via the Jakarta EE Specification Process.

[kwsutter]

Shouldn't we allow teams to release the API-jar as well if the JavaDoc is updated? It's part of the same source and CI jobs and is staged along with the JavaDoc It feels like extra work to figure out how to only release a couple of the staged artifacts to Maven Central.

Updated the "Note" to indicate that API can have a third digit service release for the Javadoc.

[kwsutter]

I think the versioning of spec documents is something we need to bring up in the spec committee.

I recall having a conversation with Bill on this topic long time ago and to make it short - now I've found: https://eclipse-ee4j.github.io/jakartaee-platform/Versioning:

For a spec of version X.Y, the spec document will be version “X.Y” for the initial release or “X.Y Rev L”, where “L” is a letter nominally starting with “a” and incrementing as more errata are approved via the Jakarta EE Specification Process.

The EMO has also created the following Issue for the EFSP to possibly define an Errata update separate from the Service Release: EclipseFdn/EFSP#32 Maybe something like this would help with potential updates to the Specification itself?

[kwsutter]

These additional discussions about a potential "service release" for the Specification are all good, but they go beyond the current definition of a Service Release. So, can we possibly just get the approvals on this template update in place so that the other Service Release issues can make progress? Thanks.

[ivargrimstad]

These additional discussions about a potential "service release" for the Specification are all good, but they go beyond the current definition of a Service Release. So, can we possibly just get the approvals on this template update in place so that the other Service Release issues can make progress? Thanks.

Agree! Just approved

[kwsutter]

Thanks, @ivargrimstad! Going ahead with the merge since we have several service releases queued up...

[lukasj]

The EMO has also created the following Issue for the EFSP to possibly define an Errata update separate from the Service Release: EclipseFdn/EFSP#32 Maybe something like this would help with potential updates to the Specification itself?

That issue is trying to define errata as a "living document" external to the specification document, so it is not going to help us to fix #318 in specification documents where we basically need to provide new revision of the document (another case - consider CVE in the spec document itself, which is unlikely but it's just HTML/PDF after all, how are we going to deal with that?)