Skip to content

Conversation

@sarahchen6
Copy link
Contributor

Changing the name distinguishes the latest "stable" image VS. "latest non-LTS" stable version. This will be relevant once LTS version JDK 25 comes out in September 2025. We would then test against JDK 24 (then JDK 26 and so on) alongside JDK 25, which should be separately pinned as LTS.

Copy link
Contributor

@bric3 bric3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: What would be the value of latest_non_lts when 25 is out, ie there's no non lts for 6 months until jdk 26 gets released ? Before 25, its value would be 24. But I don't think we'll test 24 once 25 is released, shall we "not publish" anything if there's no non lts version?.

EDIT: clarified my original thought

@sarahchen6
Copy link
Contributor Author

thought: What would be the value of latest_non_lts when 25 is out ? Before 25, its value would be 24. But I don't think we'll test 24 once 25 is released, shall we "not publish" anything if there's no non lts version?.

@bric3 I was thinking that we would keep 24 testing once 25 is released and then change latest_non_lts to 26 after 26 is released.

Alternatively, if we keep stable, would stable refer to 24 and then 25 until 26 is released? Then we would pin 25 and move stable to 26?

Both make sense to me. I guess the question is -- after an LTS version (e.g. 25) and before the following stable version (e.g. 26) is released, do we want to keep testing for the version right before the LTS (e.g. 24)?

IMO, why not! The 25 LTS version can then always be pinned as 25 instead of as stable first. However, keeping a constantly moving pointer instead of one that jumps around LTS versions makes sense to me too.

@PerfectSlayer
Copy link
Contributor

To me, stable make sense in itself, if the stable is an LTS or not.

if we keep stable, would stable refer to 24 and then 25 until 26 is released?

Yes, stable should refer to the latest stable version available, whatever the vendor support policy is.

To me, you are trying to fix an issue with CI pipeline from the builder image.
The builder image should provide (non-EOF) LTS and latest stable version.
What the CI is running with is a CI problem. We should update our CI pipeline to skip jobs when stable equals one of the LTS we have pipeline for. WDYT?

@PerfectSlayer PerfectSlayer self-requested a review June 19, 2025 12:48
@sarahchen6
Copy link
Contributor Author

To me, you are trying to fix an issue with CI pipeline from the builder image.
The builder image should provide (non-EOF) LTS and latest stable version.
What the CI is running with is a CI problem. We should update our CI pipeline to skip jobs when stable equals one of the LTS we have pipeline for. WDYT?

That makes sense! So just to clarify -- when LTS v25 comes out, the builder image will provide both this new LTS version and stable. But in this case, our CI pipeline should skip jobs for stable, as we'll already be running the tests on the same version as the LTS-labeled image.

I'll close this PR :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants