-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EA tag moves [too early] during ramp down phase ... so EA builds no longer validate the next JDK release? #82
Comments
The symbolic EA and GA tag names (read: values for the release input of this action) work as intended: they point to the latest-and-greatest JDK offered by the website selected by the workflow. In case of
|
If you want to ensure a specific JDK is used, please specify the feature release number explicitly. Here, this action doesn't make a difference between the status of the JDK. For example, 24 stays 24 - no matter if it is in early-access, rampdown, or general-availability state. This workflow show-cases how to configure this action "across various well-known JDK version": https://github.com/junit-team/junit5/blob/abf5ac3f2e17911bd932f020d2726b01d3c68a6b/.github/workflows/cross-version.yml#L2 [...]
jobs:
openjdk:
matrix:
jdk: [ 22, 23, 24 ]
runs-on: ubuntu-latest
steps:
[...]
- name: 'Set up JDK ${{ matrix.jdk }}'
uses: oracle-actions/setup-java@v1
with:
website: jdk.java.net
release: ${{ matrix.jdk }}
version: latest
[...] |
Suppose there was such a
If we introduced a |
What if there was a sort of It would behave like
We have an action on all our repositories that periodically test with GA/EA versions. It's quite the hassle to change all those repos every time something goes into RD/RC and additionally when that non-LTS version becomes EOL. We want to be able to automatically test with the current mainline and any JDK that is in RD/RC. In this way, we would be empowered to provide useful feedback during those phases without needing to constantly keep changing every single one of our repositories. |
Just to add that we just have too many builds/libraries to manually adjust the version for a ramp down phase. That is, all our libraries have their own EA build and so I'm talking probably 25+ builds (avaje libraries and ebean orm libraries). The EA and GA tags in this respect are great, moving these versions ourselves across all our builds isn't actually practical. So yes I think we are really hoping for another tag that is most of the time the same as EA (so there is probably a lot of overlap there) but then follows the version that is about to be released. FWIW I personally don't mind if there is "overlap" like EA and EA-main point to the same thing 75% of the time. I'm just aware that all our builds are now in that "gap" and are not actually testing 23 and won't actively be testing 23 until it becomes GA. Having this ~2 month "gap" does not sound right.
It would match the EA version. The primary goal is to be actively building and testing against that next version to be released so that matches the EA version up to ramp down and then sticks to the next released version.
I think a RC tag is probably what we are looking for. |
To imagine the ideal scenario, our GitHub workflow EA/GA builds would somehow detect when they are in a ramp down period and now they build against both EA (which is now 24-EA) and the release candidate (which is now 23). So in this period they perform that extra build.
|
Support for
Those time frames usually span over a year and are large enough to be considered quasi-stable; especially as the JDK project
An interesting idea! So, what about setting up custom values for your GitHub workflow matrix like shown above? For maintaining a few workflow definitions and for use-cases that target specific releases, it's okay to specify hard-coded values: jobs:
my-jdk-ea-tests:
matrix:
jdk: [ 22, 23, 24 ] Now replace with Get matrix values from an env variable (or an external source such as a file) |
Having said that and looking at the composed keys defined in jdk.java.net-uri.properties ... #
# Early-Access Releases (Alias)
#
...
23,latest,windows,x64=https://download.java.net/java/early_access/jdk23/26/GPL/openjdk-23-ea+26_windows-x64_bin.zip
...
24,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip
...
ea,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip ... I do see a better chance to introduce support for a ea,stable,windows,x64=https://download.java.net/java/early_access/jdk23/26/GPL/openjdk-23-ea+26_windows-x64_bin.zip Usage would look like this: - name: 'Set up stable EA JDK'
uses: oracle-actions/setup-java@v1
with:
website: jdk.java.net
release: ea
version: stable |
@rbygrave and @SentryMan can you please give |
Yes, all working @sormuras - thanks !!
|
3 days ago the EA tag moved from version 23 to 24, noting that JDK 23 is not actually released until Sept 17th - approx 2 months away.
This means that from now until Sept 17 any project building using the EA tag is not actually validating the next JDK to be released which is JDK 23 and still 2 months away (as builds using EA are instead now building against 24-EA).
Q: Is this 2 month gap / window in terms of EA build validating the next released version an issue?
Q: Was the EA tag moved too early to 24-EA meaning that project builds against EA are not actually validating against JDK 23 for the next 2 months until the next release?
Q: Should there be another version tag that is like EA but would not actually change until the actual release date?
The text was updated successfully, but these errors were encountered: