linghengqian · Oct 20, 2026 · Oct 20, 2026
diff --git a/docs/changes.md b/docs/changes.md
@@ -9,6 +9,8 @@ What changed in each release, as a user notices it. GitHub's release pages list
 - 13 more distributions, the rest of what Foojay lists: AdoptOpenJDK (`adpt`, `adptj9`), Eliya (`eliya`), OJDKBuild (`ojdkbld`), OpenLogic (`opnlgc`), Red Hat (`rdht`), Semeru certified (`semcrt`), Gluon GraalVM (`gln`) and GraalVM CE for JDK 8 to 19 (`grl8`, `grl11`, `grl16`, `grl17`, `grl19`). Red Hat installs from tar.xz, and OJDKBuild on Linux, OpenLogic on macOS and Gluon GraalVM before 22.1 from zips. A `.sdkmanrc` takes SDKMAN's old identifiers for them, such as `11.0.10.j9-adpt` and `22.3.3.r17-grl`. See [distributions.md](distributions.md).
 - Mandrel and Liberica NIK install by the GraalVM version they carry again: `java@23.1.12-mandrel` and `java@23.1.8-nik` work, `vfox search java mandrel` lists every release, and `java@23-mandrel` installs the newest 23.x, `23.1.12.1-mandrel`, which runs Java 21. In October 2026 Foojay moved that version from `java_version` to `distribution_version`, and since then release 0.6.2 fails on such versions with `No JDK found`, lists one Mandrel per Java major and installs Mandrel 23.1.8 for `java@21-mandrel`. Installs it made since then keep names after the Java version (`21-mandrel`, `21.0.12.1+2-nik`), and vfox still finds them by those names; uninstall one to get what the spec means now. See [distributions.md](distributions.md#behavior-of-mandrel-and-liberica-nik) ([#106](https://github.com/version-fox/vfox-java/issues/106)).
 - The notes printed by `vfox add java`, `vfox update java` and `vfox info java` are a link to the README, which lists every short name and shows how to search a distribution. Release 0.6.2 gives five short names there but not how to list their versions, while `vfox search java` lists OpenJDK only ([vfox#390](https://github.com/version-fox/vfox/issues/390)).
+- Oracle GraalVM and GraalVM Community go by GraalVM's own version, which Foojay has given as `distribution_version` since October 2026. Release 0.6.2 reads `java_version`, which now holds the JDK's version. So it installs the feature release 25.4.4.1.1 for `java@25.0.4.1-graal`, and for `java@25-graal` whenever a feature release is out on the JDK of the newest 25.0 build, and `vfox search java graal` lists no feature release. Now `java@25-graal` installs the newest build of the 25.0 line (`25.0.5-graal` on 2026-10-20), `java@25.0.4.1-graal` installs GraalVM 25.0.4.1, and the feature release is `java@25.4.4.1.1-graal`. `java@25-graalce` installs `25.4.4.1.1-graalce` from Oracle's GraalVM Download Service, where 0.6.2 installed the same file from GitHub as `25.4.4.1-graalce` ([#105](https://github.com/version-fox/vfox-java/issues/105)).
+- A 25.0 name that release 0.6.2 installed after Foojay's change can hold a feature release: `25.0.4.1-graal` is GraalVM 25.4.4.1.1, `25.0.4-graal` is 25.2.4 and `25.0.3-graal` is 25.1.3, and the same goes for these names with `-graalce`. vfox does not install a name it already has, so if the GraalVM version that `java -version` prints differs from the name, `vfox uninstall` it and install it again. `25.0.4.1-graalce`, `25.0.4-graalce` and `25.0.3-graalce` no longer install at all, as GraalVM Community's 25.0 line ends with `25.0.2`.
 
 ## 0.6.2 (2026-10-18)
 

diff --git a/docs/development.md b/docs/development.md
@@ -44,7 +44,7 @@ A few contracts that cost time to find:
 
 ## Names
 
-Installed names are `<java_version>[-<short name>][-fx]`, with no short name for OpenJDK and Foojay's `distribution_version` in place of `java_version` for Mandrel and Liberica NIK ([versions.md](versions.md#installed-names)). `lib/distribution_version.lua` reads a spec into a version, a distribution and the JavaFX flag, in either order (`21-tem`, `tem-21`). `lib/installed_version.lua` turns a version the user typed into an installed name: the name itself first. A bare major then takes the newest installed release of it, and any other version takes the release itself or its newest build. `PreUse` stops there. `ParseLegacyFile` goes one step further and falls back to the newest installed release of the major.
+Installed names are `<java_version>[-<short name>][-fx]`, with no short name for OpenJDK, Foojay's `distribution_version` in place of `java_version` for Mandrel and Liberica NIK, and GraalVM's own version for `graal` and `graalce` ([versions.md](versions.md#installed-names)). `lib/distribution_version.lua` reads a spec into a version, a distribution and the JavaFX flag, in either order (`21-tem`, `tem-21`). `lib/installed_version.lua` turns a version the user typed into an installed name: the name itself first. A bare major then takes the newest installed release of it, and any other version takes the release itself or its newest build. `PreUse` stops there. `ParseLegacyFile` goes one step further and falls back to the newest installed release of the major.
 
 SDKMAN spells some things differently (`jbr`, `21.0.12.fx-zulu`, `21.0.12-fx+1.1-librca`, `28.0.0+ea.19-open`), and `plugin_spelling` in `hooks/parse_legacy_file.lua` rewrites them into the plugin's before parsing. For the distributions SDKMAN no longer lists, `sdkman_flavours` there turns the virtual machine or JDK in SDKMAN's version into the short name (`22.3.3.r17-grl` is `22.3.3-grl17`). `installed_version.unpad` drops the zeros SDKMAN pads releases with (`27.0.0+36` is `27+36`). Where the short names differ from SDKMAN's is in [distributions.md](distributions.md#short-names-and-sdkman).
 
@@ -55,9 +55,10 @@ SDKMAN spells some things differently (`jbr`, `21.0.12.fx-zulu`, `21.0.12-fx+1.1
 - Windows asks for `zip` and `tar.gz` in one request. JetBrains Runtime ships Windows zips for its newer builds only. `PreInstall` takes the zip when a version has both.
 - Elsewhere `other_archive_type` in `lib/foojay.lua` adds one archive type for the distributions that ship no tar.gz there for some or all releases: `tar.xz` for Red Hat, `zip` for OJDKBuild, OpenLogic and Gluon GraalVM. vfox unpacks both, and the zips carry their Unix permissions, so `bin/java` stays executable.
 - `own_numbers` in `lib/foojay.lua` holds Mandrel and Liberica NIK, which carry the GraalVM version they are built from. Foojay gives it as `distribution_version` and the Java version as `java_version`, for Mandrel the major only, so these two are asked for with `distribution_version` and an empty `version`. Foojay matches the numbers given (`23.1.12` lists 23.1.12.1 too), so a longer version keeps only its own release, and a bare major takes the newest itself, as `latest=available` picks an older one for them. The answer is sorted newest first, then by the newest Java for a release that comes for several, then by BellSoft's later build for the same Java, which only the file name carries. `distribution_version` then goes into `java_version`, so the hooks name and list them like the rest.
+- Oracle GraalVM and GraalVM Community go by GraalVM's own version, which Foojay has given as `distribution_version` since October 2026, with the JDK's as `java_version`. `graalvm_packages` in `lib/foojay.lua` asks for every package, the question `vfox search` asks, so that installing sees the builds a search lists ([foojay.md](foojay.md#the-versions-of-one-distribution)). It renames each package after GraalVM's version (`graalvm_version`: the newer of `java_version` and `distribution_version`, as GraalVM Community's feature releases are also listed the old way round), sorts them newest first, and keeps those of a bare major, or the release a longer version names, without its zero padding. For `vfox search` it keeps a download once, under the newer of its two names (`25.4.4.1.1`, not `25.4.4.1`). `latest=available` is not used for them, as it misses releases: on 2026-10-20 its answer for 25 on Windows had GraalVM `25.0.4.1` but not `25.0.4.1.1`, both Java 25.0.4.1. Early-access builds still go by `version`.
 - `fixes` in `lib/foojay.lua` drops packages before the hooks see them: the JREs, installer bundles and RHEL 6 builds that Foojay lists among OJDKBuild's Windows JDKs, and the JDK 11 builds of Gluon GraalVM's 22.x releases, which share their version with the JDK 17 ones. For a bare major `latest=available` answers with one package per archive type, which can be one the fix drops, so for these two the plugin then asks for that release in full.
 - `Available` lists a name once where Foojay has two records for it.
-- Foojay marks GraalVM's monthly feature releases (`25.1.3` and on) as LTS. `is_feature_release` in `lib/distribution_version.lua` recognises them, by the minor number, and `Available` drops the note. It is for `graal` and `graalce` only: Mandrel and Liberica NIK carry GraalVM's older numbers up to 24, whose minor is no feature release (`mandrel` `23.1.12` is LTS), and the JDK's from 25 on.
+- Foojay marks GraalVM Community's monthly feature releases (`25.1.3` and on) as LTS where it lists them the old way round, as it did Oracle GraalVM's. `is_feature_release` in `lib/distribution_version.lua` recognises them, by the minor number, and `Available` drops the note. It is for `graal` and `graalce` only: Mandrel and Liberica NIK carry GraalVM's older numbers up to 24, whose minor is no feature release (`mandrel` `23.1.12` is LTS), and the JDK's from 25 on.
 - For a bare major of Oracle GraalVM (`graal`) only, `PreInstall` skips the feature releases, so the 25.0 line is installed. A major that has nothing but feature releases keeps them. GraalVM Community is not filtered, because its feature releases are what it still ships.
 - The CPU names are `arm64` to `aarch64`, and on Windows `amd64` to `x64`. `darwin` becomes `macos`. On Linux `ldd --version` decides between glibc and musl.
 
@@ -89,7 +90,7 @@ vfox plugin run . ParseLegacyFile --input '{"filename":".sdkmanrc","filepath":"/
 
 1. Find its id in Foojay ([foojay.md](foojay.md)), and check that it has packages for the platforms you care about.
 2. Add `["<short name>"] = "<foojay id>"` to `short_name` in `lib/distribution_version.lua`. Use SDKMAN's identifier when SDKMAN has or had the distribution. Otherwise make one the way SDKMAN does: keep a short vendor name whole, and cut a longer one down, mostly by dropping vowels (`opnlgc`). If SDKMAN spells it differently, map it in `plugin_spelling` in `hooks/parse_legacy_file.lua`, and add the difference to [distributions.md](distributions.md#short-names-and-sdkman).
-3. If its version numbers or its LTS marks need special care, as GraalVM's do, handle that in `hooks/available.lua` and `hooks/pre_install.lua`. If it ships no tar.gz outside Windows, add its archive type to `other_archive_type` in `lib/foojay.lua`, and if Foojay lists packages of it that do not install as they are, add a fix to `fixes` there.
+3. If its version numbers need special care, as those of GraalVM and Mandrel do, handle them where `lib/foojay.lua` reads Foojay's answer (`graalvm_packages`, `own_numbers`), and its LTS marks or the pick for a bare major in `hooks/available.lua` and `hooks/pre_install.lua`. If it ships no tar.gz outside Windows, add its archive type to `other_archive_type` in `lib/foojay.lua`, and if Foojay lists packages of it that do not install as they are, add a fix to `fixes` there.
 4. Add a case to `tests/pre_install_test.lua`.
 5. Update the tables in `README.md`, [distributions.md](distributions.md) and [platforms.md](platforms.md), and their translations in `README_CN.md` and `docs/zh-CN`.
 6. For a new code path, also add it to the e2e matrix ([e2e.md](e2e.md)). Distributions outside the matrix still run every check except the `java.vendor` assertion and the asdf-style `PreUse` spelling. One that only brings a name goes into `nameOnly` in `tests/e2e/common/common.go` instead, with the runner platforms Foojay has it for.

diff --git a/docs/distributions.md b/docs/distributions.md
@@ -130,7 +130,7 @@ IBM Semeru Runtime Certified Edition: Semeru's OpenJ9 runtimes, certified agains
 
 ### Oracle GraalVM (`graal`)
 
-Oracle's distribution of GraalVM, built on Oracle JDK. Releases carry GraalVM's numbers: `17.0.12-graal`, `25.0.4.1-graal`.
+Oracle's distribution of GraalVM, built on Oracle JDK. Releases carry GraalVM's numbers: `17.0.12-graal`, `25.0.4.1.1-graal`, `25.4.4.1.1-graal`.
 
 ### GraalVM Community (`graalce`)
 
@@ -166,9 +166,12 @@ GraalVM CE 8 to 19, Gluon GraalVM before 23, and Mandrel and Liberica NIK before
 
 ### Behavior of Oracle GraalVM and GraalVM Community
 
-- Since 25.1 (June 2026) GraalVM puts out a feature release every month next to its 25.0 line: `25.1.3`, `25.2.4`, `25.3.4.1`, `25.4.4.1`. Each is replaced within about a month. Foojay marks them LTS because the JDK they build on is LTS, and `vfox search` leaves the LTS note off them.
-- `java@25-graal` installs the newest build of the 25.0 line (`25.0.4.1-graal`), the line Oracle's own `25/latest` download follows. A feature release needs its full version: `java@25.4.4.1-graal`.
-- GraalVM Community's 25.0 line ended with `25.0.2`, and the feature releases are all it still ships. `java@25-graalce` installs the newest of them, `25.4.4.1-graalce` on 2026-10-18.
+- Since 25.1 (June 2026) GraalVM puts out a feature release every month next to its 25.0 line: `25.1.3`, `25.2.4`, `25.3.4.1`, `25.4.4.1.1`. Each is replaced within about a month. Foojay marks Oracle GraalVM's STS, but GraalVM Community's LTS where it lists them the old way round (see below), as the JDK they build on is LTS. `vfox search` leaves the LTS note off them all.
+- Releases are named after GraalVM's own version, which Foojay gives as `distribution_version`. Foojay's `java_version` is the JDK's version, which a feature release shares with the 25.0 line: `25.4.4.1.1-graal`, `25.3.4.1-graal`, `25.0.4.1.1-graal` and `25.0.4.1-graal` all have the `java_version` 25.0.4.1.
+- Foojay lists GraalVM Community's feature releases under GraalVM's version too, as it did before October 2026, with downloads from GitHub. So `java@25.4.4.1-graalce`, the name release 0.6.2 gives the 25.4.4.1.1 build, still installs it from GitHub, while `java@25.4.4.1.1-graalce` gets the same file from Oracle's GraalVM Download Service.
+- Unreleased: release 0.6.2 names releases after `java_version`, so `java@25.0.4.1-graal` installs the feature release 25.4.4.1.1, `java@25-graal` installs a feature release whenever one is out on the JDK of the newest 25.0 build, and `vfox search java graal` lists no feature release.
+- `java@25-graal` installs the newest build of the 25.0 line (`25.0.5-graal` on 2026-10-20), the line Oracle's own `25/latest` download follows. A feature release needs its full version: `java@25.4.4.1.1-graal`.
+- GraalVM Community's 25.0 line ended with `25.0.2`, and the feature releases are all it still ships. `java@25-graalce` installs the newest of them, `25.4.4.1.1-graalce` on 2026-10-20.
 - The plugin sets `JAVA_HOME` and `PATH`, and no `GRAALVM_HOME`. A `GRAALVM_HOME` that points at a GraalVM of your own stays as it is, and the native-image build plugins fall back to `JAVA_HOME` when it is unset.
 - There is no Windows ARM64 and no Alpine build, and Intel Macs get nothing after 25.0.1. See [platforms.md](platforms.md#graalvm).
 

diff --git a/docs/e2e.md b/docs/e2e.md
@@ -82,13 +82,21 @@ JDK, so `java` can only come from what vfox installs:
    build number: Foojay reads an unencoded `+` as a space and drops the
    build, and the release's newest build would install instead.
 3. On the GraalVM Community rows, Oracle GraalVM's bare major `25-graal`
-   installs the newest build of its 25.0 line (`25.0.4.1-graal`), the line
-   Oracle's own `25/latest` download follows, not one of the monthly feature
-   releases Foojay lists before it (`25.4.4.1-graal`). The builds of 25 that
-   `vfox search java graal` lists are faked as installed first, so
+   installs the newest build of its 25.0 line (`25.0.5-graal` on
+   2026-10-20), the line Oracle's own `25/latest` download follows, not one
+   of the monthly feature releases listed before it (`25.4.4.1.1-graal`).
+   `vfox search java graal` must list those under GraalVM's own version,
+   and mark the other releases of 25 alike, as in item 5. The plugin used to
+   name them after the JDK version Foojay has given them since October 2026,
+   which they share with the 25.0 line: the search then listed no feature
+   release, and `25.0.4.1-graal` had no LTS note and installed 25.4.4.1.1.
+   The builds of 25 that the search lists are faked as installed first, so
    `vfox install` names the one `PreInstall` picked and nothing downloads.
    GA 25 is left out, as vfox would find `25-graal` itself installed without
-   asking `PreInstall`.
+   asking `PreInstall`. The search and `PreInstall` ask Foojay the same
+   question, so they see the same builds
+   ([foojay.md](foojay.md#the-versions-of-one-distribution)): a build that
+   only `PreInstall` saw would download and fail the check.
 4. On the Temurin rows, which run on every runner, the distributions the
    suite checks by name only (`adpt` to `semcrt`, `nameOnly` in
    `tests/e2e/common`) go by their short names where Foojay has packages of
@@ -114,8 +122,11 @@ JDK, so `java` can only come from what vfox installs:
    `21.0.8+9-tem`). `vfox search java <distribution>` (the `Available` hook)
    lists that same name as installed, noting JavaFX on `-fx` builds. For
    GraalVM it must also list the feature releases GraalVM ships every month
-   since 25.1 (`25.4.4.1-graalce`), none of them noted LTS, though Foojay
-   marks them LTS, as the JDK they build on is; each lasts about a month.
+   since 25.1 (`25.4.4.1.1-graalce`), none of them noted LTS, though Foojay
+   marks some of them LTS, as the JDK they build on is; each lasts about a
+   month. Every other release of a major must carry the same note. The
+   plugin used to list the feature release 25.4.4.1.1 as `25.0.4.1-graalce`,
+   without the LTS note `25.0.2-graalce` has.
    On Windows the list includes JetBrains Runtime 21.0.5, which ships only as
    tar.gz there.
 6. Before any `vfox use`, a `.sdkmanrc` holding the SDKMAN identifier