Vote: Should api/spec and tck/tck-dist have diverging service releases?

[KyleAure]

Description

For service release #511 we have changes to the TCK and TCK distribution modules that need a service release.
There are no changes to the api or spec modules (except for plugin dependency updates)

Arguments

For divergence

• Possibility to do more frequent service releases for TCK changes.
• The tag is simply on what is released. So 3.1.0-API-RELEASE is one tag, and 3.1.1-TCK-RELEASE is another.

Against divergence

• For Jakarta EE 10 we always had parallel service releases
• We would need to update our build process (Jenkins jobs) to allow for this type of release structure
• We would would have to create more complex GitHub branches (ex. RELEASE-API-3.1.0-TCK-3.1.1)
• Diverging releases would naturally lead to the question "Why not put the TCK into it's own project?" which we decided to manage together to get the benefit of allowing parallel API and TCK updates.

Voting options

👍🏼 : Diverge service releases -- api and spec will stay at 3.1.0 and tck and tck-dist will be released at 3.1.1
👎🏼 : Keep parallel service releases -- api, spec, tck, and tck-dist will be released at 3.1.1

Voting Process

1. If you have any other for/against arguments to be made please comment them below.
   • I will add them to the running argument list
2. Vote by reacting to this issue with either a 👍🏼 (for) or 👎🏼 (against) vote
3. Voting will end in 1 week : June 18th 2024 @ 12:00PM CDT

[arjantijms]

To the best of my knowledge, and as discussed in the platform call, no other EE specifications have releases of API artefacts if only the TCK changed.

My vote is based on internal consistency within Jakarta EE, not necessarily of what is objectively "the best" (if even there is a "best"),

[arjantijms]

We would need to update our build process (Jenkins jobs) to allow for this type of release structure

That should not be necessary. The concurrency jobs are based on the same jobs that are used for many other EE projects, and those all do individual releases.

We would would have to create more complex GitHub branches (ex. RELEASE-API-3.1.0-TCK-3.1.1)

It doens't have to be that complicated. The tag is simply on what is released. So 3.1.0-API-RELEASE is one tag, and 3.1.1-TCK-RELEASE is another.

[arjantijms]

which we decided to manage together to get the benefit of allowing parallel API and TCK updates.

IMHO it's not just for that benefit, if at all. It's mostly for organisation. The jakartaee org is already kinda big, so having everything related to project-X in one repo is easier for navigation.

Other than that, a major reason is consistency again. Either all projects have separate repos for everything, or none should have them (IMHO). At the moment the majority of projects have everything in one repo.

[smillidge]

From memory I don't think specs have a third level service release version number?

[mswatosh]

From memory I don't think specs have a third level service release version number?

I did a quick check and it looks like other spec have occasionally had service release numbers. (e.g. Validation had a 3.0.1 and 3.0.2)

[KyleAure]

We would need to update our build process (Jenkins jobs) to allow for this type of release structure

That should not be necessary. The concurrency jobs are based on the same jobs that are used for many other EE projects, and those all do individual releases.

As it stands right now the the following jobs release all project artifacts (API/SPEC/TCK/TCK-Dist) to maven central and automatically increment all of the module versions and push them to a branch in GitHub.

• concurrency_api_1-build-and-stage
• concurrency_api_3-staging-to-release

There would be major refactoring needed of these jobs to support releasing API and TCK artifacts separately. Believe me I've worked with these jobs a lot recently 😆 @arjantijms

[arjantijms]

There would be major refactoring needed of these jobs to support releasing API and TCK artifacts separately. Believe me I've worked with these jobs a lot recently 😆

Strange, I'll take a look at what changed then. As mentioned, most other projects use the exact same jobs and they all release independently. Maybe someone did a lof of refactoring on those jobs so that they diverged from their orginals.

I mean, even the name (still) indicates that they should only ever have released the api. concurrency_api_1-build-and-stage means that the API artefact should be build and staged. If soneone altered these jobs to also release SPEC/TCK/TCK-Dis, then the purpose the job had in the first place might have been misunderstood.

There should have been an other job created called concurrency_tck_1-build-and-stage that just builds the distribution and stages that. There is no job needed really for SPEC and TCK. SPEC is done via a PR to jakarta/specifications, and TCK is already included in TCK-Dis.

[KyleAure]

If someone altered these jobs to also release SPEC/TCK/TCK-Dis, then the purpose the job had in the first place might have been misunderstood.

I think it's because we never did any refactoring of these jobs when we added the TCK and TCK-Dist to this repository which originally had these as part of the platform TCK. So our Jenkins jobs just release everything as it was before we we added these modules.

[mswatosh]

I think this far into EE11 it's not worth making the changes to the builds. If most of the other specs are releasing separately, then it's something we should consider for Concurrency 3.2

[KyleAure]

Closing vote:
3: 👎🏼 : Keep parallel service releases
2: 👍🏼 : Diverge service releases