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). 🙂