search

jakartaee / concurrency

Eclipse Project for Concurrency Utilities
https://projects.eclipse.org/projects/ee4j.cu
Other
66 stars 38 forks source link

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

Closed KyleAure closed 3 weeks ago

KyleAure commented 4 weeks ago

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

Against divergence

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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

mswatosh commented 4 weeks ago

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 commented 4 weeks ago

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.

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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