fix(nightly): monotonic sub-day nightly versions#841
Merged
Conversation
…onic Nightly versions used YYYYMMDD; two cuts on the same day produced an identical version string that the updater's _version_tuple comparison couldn't distinguish, so `hal0 update --channel nightly` would silently skip the new build. Switch the nightly workflow stamp to YYYYMMDDHHMMSS so every cut is strictly greater. _version_tuple, _NIGHTLY_RE, and nightlies_to_prune required no logic changes — they already handle variable-length numeric segments. Rename the `date` param to `stamp` in nightly_version/nightly_tag and update docstrings throughout. Regression tests added for both the channel helpers and the _version_tuple ordering. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Nightly versions were date-only (
YYYYMMDD). Two cuts on the same calendar day produced the same version string, e.g.0.5.1-nightly.20260615. The updater's_version_tuplecomparison saw no change andhal0 update --channel nightlysilently skipped the newer build.Fix
.github/workflows/nightly.yml: stamp changed fromdate -u +%Y%m%d→date -u +%Y%m%d%H%M%S, producingYYYYMMDDHHMMSS(e.g.0.5.1-nightly.20260615143022). Every cut is now strictly monotonic.src/hal0/release/channel.py: renameddateparam tostampinnightly_version/nightly_tag; updated all docstrings to document the new format and explain backward-compatibility with legacy date-only tags.No logic changes needed
_version_tuplesplits on.and int-parses each segment, stripping non-digits.(0,5,1,20260615143022) > (0,5,1,20260615)already holds._NIGHTLY_REandnightlies_to_pruneboth already handle any-length digit strings. Only stamps, docstrings, and tests changed.Backward compatibility
Legacy
YYYYMMDDtags order correctly below anyYYYYMMDDHHMMSStag with the same date prefix (8-digit integer < 14-digit integer). Pruning also sorts them correctly.Tests added
test_nightly_version_uses_full_stamp_and_is_monotonic— verifies the new stamp passes through verbatimtest_nightlies_to_prune_orders_by_full_numeric_stamp— verifies legacy date-only tag sorts below timestamp tags and is pruned firsttest_version_tuple_timestamp_nightly_beats_date_only_same_base— regression-locks_version_tupleordering for timestamp vs. date-only nightliesAll 62 tests pass (
tests/release/+tests/updater/).🤖 Generated with Claude Code