Only the newest Java line is maintained from now on. Publishing the chart once
per line out of one directory is what made the lines drift apart (#158): a
change reached whichever line happened to lie in the directory. java8 and java17
stay published as frozen artifacts at 4.0.0, java21 at 4.1.0, and none of them
gets another chart change.
Running an older JVM is now a decision at rollout time instead of a chart
version: image.tagOverride replaces the tag that otherwise comes from
appVersion. It is not called image.tag because it decouples the running image
from the chart version, and it is deliberately outside Renovate's reach -
renovate.json5 keeps tracking appVersion only.
The pairing of tag and minecraft.version is now checked at render time and fails
with both values named, the line each one belongs to, and where the tag came
from. Until now nothing checked it: a mismatch installed silently and only the
container failed afterwards. The boundaries are Mojang's, swept over all 102
releases of the piston-meta manifest (javaVersion.majorVersion): up to 1.16.5
Java 8, 1.17-1.17.1 Java 16, 1.18-1.20.4 Java 17, 1.20.5-1.21.11 Java 21, 26.1
and later Java 25. The 1.17 line was the one gap the chart's own notes did not
cover.
Two cases pass unchecked on purpose, documented in values.yaml and NOTES.txt: a
tag without a recognizable java<N> part, and a minecraft.version that is not a
plain numeric x[.y[.z]]. A guard that rejects what it does not understand gets
worked around instead of respected.
Major, because an installation that already runs a mismatched pair stops
rendering. It does not run today either - it now fails earlier and visibly.
Minecraft 26.2 requires Java 25, so the chart's default minecraft.version can
only be raised on a java25 image. appVersion becomes 2026.8.2-java25 - the same
dated upstream release the java21 line ships, so the only variables that change
are the JVM and the Minecraft version.
The chart version stays at 4.1.0: the Java lines are siblings of one chart
generation, not successors, and are told apart by the +up suffix.
The Java boundaries in the values.yaml / NOTES.txt comments are read off
Mojang's version manifest (javaVersion.majorVersion per release), not
estimated: 1.21.11 is the last release asking for Java 21, every release from
26.1 on asks for Java 25.
Teil von #157 and Teil von #43, in one change because both are additive and
neither moves a rendered object.
#157 - multiplyQuantity turned large numbers into exponential notation. The
null-safe fallback helpers pass values through fromYaml, which parses every
number as float64, and Go's "%v" switches float64 to exponential notation from
about 1e6 upwards. A bare byte count like 1048576 became "1.048576e+06".
The chart has two affected positions, and they fail differently:
- the entry of multiplyQuantity aborts the render loudly, because the
exponent is caught by the suffix check
(unsupported resource quantity suffix "e+06").
- the output of a non-integer product never reaches that check and renders
silently: a fractional limitFactor together with a bare number produced
"1.4999985e+06" in the manifest, rejected only later by the API server.
Note that this chart's schema types limitFactor as "number" with
exclusiveMinimum 0, not as an integer, so the silent path is reachable here
through ordinary values.
Both positions now go through a new minecraft-server.formatNumber helper, the
canonical correction already applied to template-chart, voucher-vault, zipline,
outline and minecraft-router.
#43 - NOTES.txt for this chart. It prints what an operator would otherwise have
to read out of the templates, conditional on the values actually set:
- access, which is not a URL: ClusterIP means the server is reachable only
once its Service name is entered in the minecraft-router release's static
mappings, since that router does no auto-discovery; NodePort prints the
node port and warns when it falls outside 30000-32767.
- the Java line, derived from appVersion rather than written into the file,
so it holds for all three published lines, together with the fact that
nothing checks minecraft.version against it.
- what a green rollout does not prove. The probes do run a real server-list
ping, so Ready means the server answers - but a ping is answered before any
login, so every login-side refusal is invisible to all three probes. The
whitelist is the practical case: enabled without players locks everyone out
while the rollout stays green.
- which fields the 1Password item must carry, listed only for the features
actually enabled, plus the documented gap that a changed item content does
not roll the pod.
- the world PVC that helm uninstall deletes, the two memory numbers and how
they decouple, RCON not being published by the Service, the declared but
unserved metrics port, and the enabled modpack source.
No real domain anywhere; the router example uses mc.example.com.
Verified: helm lint --strict clean on all three Java lines; rendering the CI
values and the chart defaults is byte-identical to origin/main, so no
Kubernetes object changes and the minor bump is the right one.
jklein