feat(extension): derive the version as unpadded CalVer (milestone 318 step 8)
Build images / build-ml (push) Successful in 4s
CI / lint (push) Successful in 4s
Build images / build-agent (push) Successful in 5s
CI / extension-version (push) Successful in 4s
CI / frontend-build (push) Successful in 22s
extension / lint (push) Successful in 22s
CI / backend-lint-and-test (push) Failing after 33s
Build images / sign-extension (push) Successful in 2m24s
Build images / build-web (push) Successful in 2m38s
CI / integration (push) Successful in 5m15s
Build images / build-ml (push) Successful in 4s
CI / lint (push) Successful in 4s
Build images / build-agent (push) Successful in 5s
CI / extension-version (push) Successful in 4s
CI / frontend-build (push) Successful in 22s
extension / lint (push) Successful in 22s
CI / backend-lint-and-test (push) Failing after 33s
Build images / sign-extension (push) Successful in 2m24s
Build images / build-web (push) Successful in 2m38s
CI / integration (push) Successful in 5m15s
`1.0.<minutes since 2020>` -> `YYYY.M.D.HHMM` UTC, from the commit time of
the newest change to a packaged extension file. Same clock and same commit as
before; readable instead of opaque, and the same value the rest of the family
derives.
The hold on this step was two questions about AMO, and Mozilla's own docs
answer both:
^(0|[1-9][0-9]{0,8})([.](0|[1-9][0-9]{0,8})){0,3}$
1. four all-numeric segments -> ACCEPTED ({0,3} more after the first).
2. leading zeros -> REJECTED. A segment is the single digit
`0` or starts 1-9, so `08` and `0201` are refused. MDN says it in prose
too: "Non-zero numbers must not include a leading zero."
So the documented fallback applies, extension only: the same numbers rendered
without the family's zero-padding. `2026.08.29.0201` and `2026.8.29.201` are
one value in two renderings — rule 148 defines comparison as numeric per
segment, under which they are equal — so nothing already published is
reordered, and left-padding each segment recovers the family string exactly.
HHMM stays one segment because AMO allows at most four.
The transition is safe in the other direction too: 2026 > 1, so every CalVer
outranks every published 1.0.x. build.yml's downgrade guard confirms it.
Also in scope:
* MAJOR.MINOR is gone. `cmd_major_minor`, `cmd_patch` and VERSION_EPOCH go
with it, the committed version in manifest.json / package.json is now
wholly inert, and ci.yml's MAJOR.MINOR-agreement check is retired rather
than left running beside a fact that stopped existing (rule 22).
* ci.yml's `extension-version` lane now asserts Mozilla's regex verbatim
instead of a loose `^[0-9]+(\.[0-9]+)*$` — which would have passed the
padded shape. It also asserts YYYY.M.D.HHMM, because AMO would accept a
regression to `1.0.<minutes>` while that orders below everything signed
since. Checking here is the point: AMO 409s on re-signing, so a version it
rejects is burned and cannot be reused.
* `artifacts.sh version extension` delegates to packaging.sh, so the two
cannot answer differently. The direction matches the existing one —
artifacts.sh already asks packaging.sh for the extension's path set.
#3156 is what makes this commit safe to make: packaging.sh is in web's path
set, so the web revision moves with the extension version and build-web
rebuilds instead of republishing an image bundling the previous XPI.
Scribe #3138.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -75,18 +75,23 @@ jobs:
|
||||
fetch-depth: 0
|
||||
|
||||
# The version is DERIVED, not read from the repo (milestone 271 step 4,
|
||||
# cut over 2026-08-27). `packaging.sh version` returns MAJOR.MINOR from
|
||||
# manifest.json plus a patch component that is the commit TIME of the
|
||||
# newest change to a PACKAGED extension file, in minutes since
|
||||
# 2020-01-01 — family rule 149, never a commit count, which orders by
|
||||
# cut over 2026-08-27). `packaging.sh version` returns `YYYY.M.D.HHMM`
|
||||
# UTC — the commit TIME of the newest change to a PACKAGED extension
|
||||
# file, per family rule 148/149. Never a commit count, which orders by
|
||||
# branch rather than by recency.
|
||||
#
|
||||
# The committed "version" in manifest.json / package.json no longer
|
||||
# decides anything: the stamp step below overwrites it in the working
|
||||
# tree before web-ext ever reads it. It is deliberately NOT committed
|
||||
# back — the commit carrying the bump would itself be a change to the
|
||||
# extension and would move the version again. The repo holds the source;
|
||||
# the build derives the label.
|
||||
# Unpadded, and only here: AMO's grammar rejects a leading zero, so the
|
||||
# extension renders rule 148's numbers without the family's padding
|
||||
# (milestone 318 step 8). Same value, one character narrower per segment;
|
||||
# ci.yml's extension-version lane checks the string against Mozilla's
|
||||
# published regex before this job ever calls AMO.
|
||||
#
|
||||
# The committed "version" in manifest.json / package.json decides NOTHING
|
||||
# — not even a MAJOR.MINOR prefix, which step 8 removed. The stamp step
|
||||
# below overwrites it in the working tree before web-ext ever reads it,
|
||||
# and it is deliberately NOT committed back: the commit carrying the bump
|
||||
# would itself be a change to the extension and would move the version
|
||||
# again. The repo holds the source; the build derives the label.
|
||||
- name: Derive extension version
|
||||
id: extver
|
||||
run: |
|
||||
|
||||
Reference in New Issue
Block a user