Explicitly set the LATEST_VERSION of Java we build

[sarahchen6]

This PR re-introduces a bit of upkeep; However, it would be a minuscule change at max twice a year. And, whenever we increment the LATEST_VERSION of Java that we're testing, we will already need to make code changes such as updating tests, resolving incompatibilities, etc.

I think this change provides a bigger benefit in making LATEST_VERSION explicit -- no need to check calculations, but open to other opinions!

[PerfectSlayer]

This PR re-introduces a bit of upkeep

The goal was originally to automate the most possible this repository to be maintenance free (hence the "keep up to date" automation to keep the worklow running).
I feel like once you move to some other topics, you tend to forget about it and maintenance cost / context switching become a burden.

I think this change provides a bigger benefit in making LATEST_VERSION explicit

To me, this won't make it explicit. You can't tell which specific version ends up in the built image.
To address this issue, the build already has a mechanism to describe and report what was built and tagged. Here is an example: https://github.com/DataDog/dd-trace-java-docker-build/actions/runs/16093503330

we will already need to make code changes such as updating tests, resolving incompatibilities, etc.

Yes, but those changes are 1. automated (ie the upgrade of the docker image is done using a workflow and creates a PR for) 2. located in the dd-trace-repo only (which helps to people onboard to fix any compatibility issue).

open to other opinions!

My question would be why was the main reason you wanted to get rid of the compute_latest_version(). Was it because it feels implicit? (as all other docker images we rely on) Was it because it felt cumbersome to read? Anything else?

[sarahchen6]

My question would be why was the main reason you wanted to get rid of the compute_latest_version(). Was it because it feels implicit? (as all other docker images we rely on) Was it because it felt cumbersome to read? Anything else?

A couple more thoughts about getting rid of compute_latest_version():

• Yes - it adds a bit of complexity when reading the code (e.g. need to do a calculation to figure out what LATEST_VERSION refers to instead of just reading its assignment).
  • As you mentioned above though, this can be confirmed with ./build --describe
• Seems like we should update the LATEST_VERSION we work with when we the developers are ready for it (e.g. what if we want the version updated the immediate day after its release instead of the following month, or what if we need an extra few months?).
  • The first question can be resolved with a more detailed compute_latest_version() that calculates on the day as well.
  • The latter question can be resolved with - since the PR to update the build image is automated, we can just wait to merge it until we're ready.
• A final point is that ubuntu seems to change their base image (e.g. noble, jammy, etc.) every two years (ref), so we would need to update the name of the base image anyway every so often.
  • Maintenance every two years when ubuntu changes their LTS version < maintenance twice a year when a new JDK version is released.

So clearly all my points are okay with leaving the method as is 😆 Just wanted to bring this up as an idea... I see your pro also that for upgrading our JDK support, we could isolate our manual efforts (as much as possible) to just the dd-trace-java repo and minimize thinking about an additional repo (i.e. this one). 🙂

[PerfectSlayer]

need to do a calculation to figure out what LATEST_VERSION refers

This is where I feel we miss documentation. LATEST_VERSION should be the latest version available according the OpenJDK lifecycle and we should be able to trust our CI / project to build the right thing, rather than having to compute what was expected to be shipped 😅

we should update the LATEST_VERSION we work with when we the developers are ready for it

To me, we should update as soon as possible. The CI might be breaking, but it should not be blocking. Team must have a feedback about their current support and fix it according their own planning. We should not wait for everyone to be "next version ready" in order to provide it to our build.

A final point is that ubuntu seems to change their base image

Yes, we won't be able to avoid this kind of maintenance... Similar thing can happen with security issue.

So far, the main goal was to automate this repository to make it work like a clockwork: provide regularly up-to-date build images with the latest tool available at the time and (trust it to) forget about it. If you're willing to actively maintain it and take care of it with manual maintenance, I'm good with that and be happy to hand it over to you :) My constraint was having limited time, so the less I had to spent its maintenance, the better it was. So it's up-to-you to shape it the way you want to maintain it!