Pin minecraft-server to dated image tags and fix the whitelist switch (2.0.0+up2026.8.2.java8)

Stage 3 of the Fleet migration. Two changes, both breaking, hence the major
bump from 1.0.0 to 2.0.0.

Dated image tags: appVersion moves from the rolling line tag "java8" to the
immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt
continuously, so a pod restart could pull a different image than the previous
start without that being recorded anywhere. 2026.8.2 is the newest upstream
release (published 2026-08-23) and exists for all three Java lines.

Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST)
in both positions, so minecraft.whitelist.enabled: false actually switches the
whitelist off. Previously the chart only emitted whitelist variables while
enabled was true and had no way to express "off" - and because server.properties
lives on the PVC, a release that had once written white-list=true kept it
forever. players stays guarded by enabled, since a non-empty WHITELIST enables
the whitelist in the image regardless of ENABLE_WHITELIST.

The default flips from enabled: true to enabled: false. Under the corrected
semantics the old default (enabled with an empty player list) would mean a
server nobody can join; false matches both the image and vanilla Minecraft.

minecraft-server/Chart.yaml

@@ -8,8 +8,13 @@ type: application
 # The Java line of this chart version is chosen through appVersion, which is
 # the image tag: the chart is published once per line (java8 / java17 / java21)
 # and minecraft.version in values.yaml must match the line published here.
-version: 1.0.0+upjava21
-appVersion: "java21"
+# Since chart 2.0.0 the tag is a DATED upstream release ("<release>-java<N>")
+# instead of the rolling line tag ("java<N>"): the rolling tags are rebuilt
+# continuously, so a pod restart could pull a different image than the last one
+# without anything being recorded anywhere. The dated tags are immutable, so the
+# image is now pinned by the chart version like every other chart in this repo.
+version: 2.0.0+up2026.8.2.java8
+appVersion: "2026.8.2-java8"
 
 maintainers:
   - name: jklein

minecraft-server/templates/minecraft-server.sfs.yaml

@@ -68,6 +68,25 @@ spec:
               value: {{ .Values.minecraft.difficulty }}
             - name: SERVER_PORT
               value: "{{ .Values.server.port }}"
+            # ENABLE_WHITELIST is set in both positions on purpose - it is the
+            # only variable that can switch the whitelist OFF again. The image
+            # enables the whitelist when WHITELIST/WHITELIST_FILE is non-empty
+            # OR ENABLE_WHITELIST is true, and disables it (white-list=false)
+            # when ENABLE_WHITELIST is false, rewriting an existing
+            # server.properties on the volume. Because a non-empty WHITELIST
+            # wins over ENABLE_WHITELIST=false, players must stay unset while
+            # disabled - hence the guard below rather than emitting both.
+            - name: ENABLE_WHITELIST
+              value: "{{ .Values.minecraft.whitelist.enabled }}"
+            # enforce-whitelist is mapped from ENFORCE_WHITELIST in the image's
+            # property-definitions.json. The image only ever sets it to true (in
+            # its enable branch) and never resets it, so without this line a
+            # server that once had the whitelist on keeps enforce-whitelist=true
+            # in its persisted server.properties after switching off. It is
+            # inert while white-list=false, but leaving stale state behind is
+            # exactly what this chart version fixes, so it follows the switch.
+            - name: ENFORCE_WHITELIST
+              value: "{{ .Values.minecraft.whitelist.enabled }}"
             {{- if .Values.minecraft.whitelist.enabled }}
             - name: EXISTING_WHITELIST_FILE
               value: {{ .Values.minecraft.whitelist.overridePolicy }}

minecraft-server/values.schema.json

@@ -156,13 +156,16 @@
           "additionalProperties": false,
           "properties": {
             "enabled": {
+              "description": "Wired to the image's ENABLE_WHITELIST in both positions: true sets white-list=true (and enforce-whitelist=true), false rewrites white-list=false into an existing server.properties on the volume. true without players locks everyone out - that is the image's semantics and it is intended.",
               "type": "boolean"
             },
             "overridePolicy": {
+              "description": "EXISTING_WHITELIST_FILE - how an already existing whitelist.json is treated. Only applies while enabled is true.",
               "type": "string",
               "enum": ["SKIP", "MERGE", "SYNCHRONIZE"]
             },
             "players": {
+              "description": "Comma-separated players, passed as WHITELIST only while enabled is true (a non-empty WHITELIST would otherwise enable the whitelist despite ENABLE_WHITELIST=false).",
               "type": ["string", "null"]
             }
           }

minecraft-server/values.yaml

@@ -153,11 +153,33 @@ minecraft:
   # Valid values are: peaceful, easy, normal, and hard
   difficulty: "easy"
   whitelist:
-    # Boolean. Before chart 1.0.0 this was the string "true" and was evaluated
-    # with a plain truthiness test, so even "false" enabled the block.
-    enabled: true
+    # Boolean, wired to the image's ENABLE_WHITELIST in BOTH positions since
+    # chart 2.0.0 - which is what makes "false" actually switch the whitelist
+    # off. server.properties lives on the PVC, so before 2.0.0 a release that
+    # had once written white-list=true kept it forever: the chart only ever
+    # emitted whitelist variables while enabled was true and had no way to say
+    # "off". Now enabled: false emits ENABLE_WHITELIST=false, and the image
+    # rewrites white-list=false into the existing file.
+    #
+    # >>> enabled: true WITHOUT players locks the server down completely. <<<
+    # That is the image's own semantics and it is intended: white-list=true with
+    # an empty whitelist.json means nobody can join - not even the ops. Set
+    # players whenever this is turned on, or leave it at false.
+    #
+    # The default is false, matching both the image and vanilla Minecraft, which
+    # start with white-list=false. (Before chart 2.0.0 the default was true with
+    # players: null; that combination did nothing back then, because an empty
+    # WHITELIST never enabled anything - under the new semantics it would be a
+    # locked-out server, so the default is flipped.)
+    enabled: false
+    # How the image treats an ALREADY EXISTING whitelist.json on the volume:
+    # SKIP leaves it alone, MERGE adds players to it, SYNCHRONIZE makes it match
+    # players exactly (removing everyone else). Only applies while enabled.
     overridePolicy: "MERGE"
-    # Comma-separated List of Players
+    # Comma-separated List of Players. Only passed to the image (as WHITELIST)
+    # while enabled is true - a non-empty WHITELIST turns the whitelist on in
+    # the image regardless of ENABLE_WHITELIST, so leaving it out is what keeps
+    # enabled: false switched off even for a release that still lists players.
     players: null
   management:
     # Comma-separated List of Players. The image resolves every name against
@@ -184,8 +206,8 @@ minecraft:
   # This value must match the Java line of the chart version: the image tag
   # comes from .Chart.AppVersion, so the JVM is fixed per published chart
   # version. Java 8 runs Minecraft up to 1.16.5, 1.18-1.20.4 need Java 17 and
-  # 1.20.5+ need Java 21. This chart publishes appVersion "java21".
-  version: "1.21.1"
+  # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java8".
+  version: "1.12.2"
 
 # curseforge, ftb and curseforgeServerpack are mutually exclusive - enabling
 # more than one is rejected by the chart (before 1.0.0 it silently rendered a