Repository navigation
build: align the version record with the 1.0.<commit_count> scheme - #270
Merged
Merged
Conversation
MARKETING_VERSION and CURRENT_PROJECT_VERSION now describe the same commit count: MARKETING is 1.0.N and the build is N, where N is the commit count of the commit that carries the change. The retired UTC YYYYMMDDHHMM build stamp is gone from project.yml, and the committed Xcode project carries the same pair so it cannot re-introduce the old value when xcodegen regenerates it.
jaywedgeworth22
enabled auto-merge (squash)
October 19, 2026 15:22
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
…t_count> The committed version record carried the retired UTC YYYYMMDDHHMM build stamp and a MARKETING_VERSION that did not match its own build number. Under the unified scheme the two always describe one number: MARKETING is 1.0.N and the build is N, where N is the commit count of the commit that carries the change. The committed Xcode project carries the same pair, so a regeneration cannot re-introduce the old value. The ship script had two defects in the operator-override path. The floor failure was swallowed, so an unreachable App Store Connect read as "floor 0" and the build number could repeat a pair ASC already holds; the auto path already refuses to ship in that case, and the override path now does the same. And MARKETING did not follow BUILD_NUM, so a ship could record a version and a build that disagree. Unless the operator pins a marketing version, MARKETING is now derived from the build. An explicit --version names a train and is honoured exactly; the floor still keeps the build unique inside it. An explicit --build is still honoured exactly. The auto path no longer advances the local build-seq counter: under the commit-count scheme it feeds neither field, so writing to it only drifts the floor on every later run.
This comment has been minimized.
This comment has been minimized.
|
🤔 Insufficient Task ContextI found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details. 🔍 What I need to validate:
💡 How to improve the task context:
|
This comment has been minimized.
This comment has been minimized.
MARKETING_VERSION is 1.0.<commit_count> and CURRENT_PROJECT_VERSION is that same integer, so the pair App Store Connect renders always names one commit. Three defects are fixed in this change: - The committed version record was set to the branch-tip commit count, which after a squash merge names a count that will never exist on main. The record is a build-number floor input, so that made it the dominant floor and permanently shipped build numbers above the commit count they were supposed to name. The record now names 234, one below main's count: a real commit, below every shipping commit, safe under any merge strategy. - The ship script still fell back to a UTC YYYYMMDDHHMM stamp when the commit count could not be read. The retired scheme must not be one error away, so a checkout with no readable git history now fails loudly instead of minting a number that describes no commit. - The local build-seq counter is no longer advanced. Under the commit-count scheme it feeds neither MARKETING nor BUILD_NUM, and writing floor + 1 to it would record a number that never shipped. Docs that still described the retired stamp are corrected in the same change, so a later reader cannot reintroduce it. Fixes AFC-356
This comment has been minimized.
This comment has been minimized.
![kody-ai[bot]](https://avatars.githubusercontent.com/in/413034?s=60&v=4){kind=small}
…counter Four problems are fixed here. A git failure while reading the commit count exited under set -e before the diagnostic could run, so the run died with no explanation at all. The retired build-seq counter was still being read as a floor input, and a leftover from the old timestamp scheme in that file could push the build number above the commit count it names. The die text blamed "there is no local sequence" for a cause that no longer exists, and the --build guidance described the wrong train. The guard comment also did not say that the guard is the one deliberate exception to the commit-count rule. The counter is never written any more, so it is retired rather than merely un-advanced: local_seq() now returns 0, and the committed version record is the floor input that remains. An explicit --build is still honoured exactly, and it moves MARKETING to the default train's N; --version <prefix>.N targets a train other than the default. Fixes AFC-356
This comment has been minimized.
This comment has been minimized.
The override log line read "sequence not consulted". That is wrong for a --version-only override: resolve_seq_floor runs whenever --build is absent, so the App Store Connect floor IS consulted there. What is genuinely not consulted is the retired local build-seq counter. The line now names the local counter, so an operator reading the log is not misled about whether the floor was checked.
This comment has been minimized.
This comment has been minimized.
The vendored ship script's comments still described a scheme the code no longer implements. This is the same documentation fix that landed in the FleetLink copy, applied here so the two do not drift apart. Four claims were wrong: - The header said the version is always 1.0.<commit_count> with no exception, and the MARKETING_VERSION block repeated that. When App Store Connect already holds that commit count, the guard moves BOTH numbers up to <floor + 1> together, so the pair stays consistent but the build number no longer names that commit. The header now states that one exception. - The sequence block described the next sequence as max(local cache, App Store Connect, project.pbxproj) + 1. The local build-seq counter is retired under the commit-count scheme: local_seq() returns 0 and nothing reads or advances the file. The floor is max(App Store Connect, project.pbxproj) and the number to ship is the commit count, raised past that floor by the guard. The counter file and next_build_seq() stay in place so a vendored script stays close to the fleet original, but neither is on the path that decides a build number. - The ship-gate list still named next_build_seq as "the consuming step". No number is consumed from a cache any more, so it is off that list. - The override branch claimed the commit count "is higher than anything already uploaded". It is usually higher, but not always; the floor raises the build number when it is not. The guard comment also said the two numbers "always describe the same commit count" while the comment directly above it said they carry one number; it now says the latter. Every changed line is a comment. No behaviour changes.
Kody Review CompleteGreat news! 🎉 Keep up the excellent work! 🚀
|
| Options | Enabled |
|---|---|
| Bug | ✅ |
| Performance | ✅ |
| Security | ✅ |
| Business Logic | ✅ |
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
1 participant
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.
Fixes AFC-356
What
Puts CodeCaps fully onto the unified fleet build-numbering scheme (owner 2026-10-18) and retires the UTC build stamp for good.
MARKETING_VERSIONis1.0.<commit_count>andCFBundleVersionis that same integer, so the pair App Store Connect renders always names one commit.project.ymland the committedproject.pbxproj) is re-aligned to234, one below main's commit count.YYYYMMDDHHMMbuild stamp is gone from the ship script, from the docs, and from the tests.Why
Three defects, all of which let a ship describe a number that no commit names.
The version record was poisoning the build floor. The ship script reads the committed record as one of its floor inputs (local cache, App Store Connect, and
project.pbxproj, whichever is highest). Under the old scheme the record held a small patch number, so it never mattered. Under the commit-count scheme it holds a large number, so it became the dominant floor: the strictly-increasing guard then fired on every ship and permanently shipped a build number one or more above the commit count it was supposed to name. The record is now234, one below main's count -- a real commit, below every commit that can ship, safe under any merge strategy and any race.The ship script still fell back to a UTC stamp.
utc_build_stamp()was dead code that existed only to mint a 12-digit stamp, and the override path auto-filledBUILD_NUMwithgit rev-list --count HEAD || date -u +%Y%m%d%H%M. One error away, the retired scheme was live again. The dead helper is removed, and a checkout with no readable git history now fails loudly instead of minting a number that describes no commit. An explicit--buildis still honoured exactly.The local build-seq counter was still being advanced. Under the commit-count scheme it feeds neither
MARKETINGnorBUILD_NUM, so writingfloor + 1to it records a number that never shipped -- the same "local counter drifting from App Store Connect" defect the 2026-08-12 gate-ordering fix addressed. The counter is no longer advanced, matching the canonical reference script.What changed
scripts/ios-fleet/ship-testflight.sh-- the three fixes above, plus the stale comment block that still describedCFBundleVersionas "a UTC timestamp, YYYYMMDDHHMM", replaced with the commit-count block. All ten fleet copies of that block are now byte-identical.project.ymland the committedproject.pbxproj-- re-aligned to234, with a comment saying what the record is for.scripts/ios-fleet.sha256-- regenerated, because the vendored ship script changed.scripts/ios-ship-workflow.test.mjs-- 8 passed.Testing
bash -n scripts/ios-fleet/ship-testflight.shnode --test scripts/ios-ship-workflow.test.mjsLet me analyze the code changes in this pull request to understand what was implemented.
The PR title is: "build: align the version record with the 1.0.<commit_count> scheme"
Key changes I can identify:
docs/IOS-TESTFLIGHT.md - Updated documentation to reflect that both marketing and build versions come from the repo's commit count (
1.0.<commit_count>and<commit_count>), and that UTCYYYYMMDDHHMMstamps are retired.ios/CodeCapsCompanion/CodeCapsCompanion.xcodeproj/project.pbxproj - Changed
CURRENT_PROJECT_VERSIONfrom 237 to 234, andMARKETING_VERSIONfrom1.0.237to1.0.234in multiple build configuration blocks.ios/CodeCapsCompanion/project.yml - Updated
MARKETING_VERSIONfrom1.0.237to1.0.234andCURRENT_PROJECT_VERSIONfrom237to234, with added comments clarifying these are a record of what shipped and serve as the build-number FLOOR for the ship script.scripts/ios-fleet/ship-testflight.sh:
utc_build_stamp()function that was retired as the primary scheme--build, the script now reads only the commit count from git, and fails loudly if it can't read it (no fallback to UTC stamp or SEQ_FLOOR + 1)SEQ_FLOOR + 1fallback that decoupled the shipped number from the commit it claimed to beThe review finding notes that there's a new comment at lines 911-913 claiming the build number names a commit, but the adjacent unchanged guard at lines 924-928 bumps to SEQ_FLOOR + 1, decoupling the pair from any commit. This is a low-severity finding about inconsistency in the script.
The functional purpose is to fully align the build/marketing versioning scheme with
1.0.<commit_count>where the build number is the repo's commit count, retiring the old UTC timestamp fallback.This PR finalizes the migration to a
1.0.<commit_count>versioning scheme for TestFlight iOS builds, fully retiring the legacy UTC timestamp (YYYYMMDDHHMM) approach and ensuring bothCFBundleVersionand the marketing version are always derived from the repository's commit count.Key changes:
Documentation (
docs/IOS-TESTFLIGHT.md): Updated the "Versions And Notes" section to describe that marketing and build numbers both come from the repo's commit count, and that UTC timestamp stamping is retired.Project version record (
project.yml/.xcodeproj/project.pbxproj): LoweredCURRENT_PROJECT_VERSIONandMARKETING_VERSIONfrom237to234across all build configurations. Added a clarifying comment inproject.ymlnoting these values are a record of what shipped and serve as the build-number floor for the ship script, not the source of truth for the next ship.Ship script (
scripts/ios-fleet/ship-testflight.sh):utc_build_stamp()helper function that produced the retired UTC-based fallback.--build/--versionoptions to describe the new commit-count-based scheme and warn that UTC timestamps no longer work.--buildis provided and no--versionis forced, the script now reads the commit count from git and fails loudly if it cannot be obtained, instead of falling back to a UTC stamp orSEQ_FLOOR + 1. This ensures the shipped build number always names the exact commit it represents.--versionoverride path and the default path.Review note: A low-severity finding remains — a newly added comment near the same-HEAD guard still describes the build number as naming a commit, while the adjacent unchanged guard bumps to
SEQ_FLOOR + 1on a re-ship, which decouples the pair. This inconsistency is left as-is in the patch but is flagged for follow-up.The user wants me to generate a precise description for this pull request based on the code changes. Let me analyze the patches carefully.
The PR is titled "build: align the version record with the 1.0.<commit_count> scheme"
Looking at the changes in
scripts/ios-fleet/ship-testflight.sh:local_seq()function (around line 385-395): The function used to read from a build-seq file. Now it just returns "0" and the comment explains that the build-seq counter is retired under the commit-count scheme - reading it would create numbers unrelated to commits.Error message in
resolve_seq_floor()(around line 485-498): The error message is updated to reflect that ASC (App Store Connect) is now the only record that advances when shipping - not a local sequence file. Also updated info about--buildand--versionflags, mentioning "train" terminology and that you can use--version <prefix>.Nto ship into a different train.BUILD_NUMline (line 871): Added|| trueto the git rev-list command. This ensures the script doesn't fail onset -estyle behavior when git can't read history.COMMIT_COUNTline (line 915): Similar|| trueaddition, plus an expanded comment explaining the guard logic - when the floor is at or above the commit count, the (version, build) pair is bumped together because shipping the commit count would repeat a pair ASC already holds.Key functional changes:
build-seq-${APP_KEY}.txt) is retired - no longer read or used|| trueto prevent script failure when git can't read historyLet me write a concise but precise description.
This change realigns
scripts/ios-fleet/ship-testflight.shwith the1.0.<commit_count>version record scheme. The local sequence file (build-seq-${APP_KEY}.txt) is retired —local_seq()now returns0instead of reading the leftover file, because advancing off it would inflate the floor above the commit count and cause the strictly-increasing guard to ship numbers that name no commit. The fallback error message is updated to reflect that App Store Connect is the only record advanced by shipping, and documents the--build/--versioninteraction for shipping into non-default trains.git rev-list --count HEADinvocations are guarded with|| trueso a shallow or unreadable checkout no longer aborts viaset -ebefore the explicit die() can produce a clear message. The auto-fill comment block is expanded to document the one deliberate exception where the (version, build) pair is bumped together — when the floor is at or above the commit count, shipping the commit count would repeat a pair ASC already holds, and shallow checkouts can underestimate the count, making the committed record the source of uniqueness.The patch shows a single modification to a log message in
scripts/ios-fleet/ship-testflight.sh. The change is purely a clarification of a log message string — replacing "sequence" with "the local build-seq counter" to be more descriptive about what "sequence" refers to.Clarifies a log message in the iOS TestFlight shipping script to explicitly reference the local build-seq counter when indicating that the operator override (via
--buildor--version) bypasses the sequence-based version resolution.The user wants me to analyze the code changes (patches) and generate a precise pull request description. Let me carefully analyze what was changed.
The pull request is titled "build: align the version record with the 1.0.<commit_count> scheme" and is from branch
minimax/afc-356-version-recordtomain.Let me examine each file:
docs/IOS-TESTFLIGHT.md - Changes a section from "CodeCaps For Mac (TestFlight)" to "CodeCaps For Mac (Retired From TestFlight)". The content has been rewritten to reflect that CodeCaps for Mac no longer ships to TestFlight. Lists what was removed (workflow files, scripts, signing configs) and what stays (targets still build but don't archive/upload).
ios/CodeCapsCompanion/project.yml - Removed the Release configuration signing overrides for the
CodeCapsCompanionMacandCodeCapsWidgetsMactargets. These overrides were configuring Apple Distribution signing for the Mac App Store. Now removed.scripts/ios-fleet/ship-testflight.sh - Multiple comment/doc updates explaining the version scheme:
max(App Store Connect, project.pbxproj)The functional impact:
CodeCapsCompanionMacandCodeCapsWidgetsMactargets no longer have Apple Distribution/Provisioning Profile specs for Release)1.0.<commit_count>and build version is the same commit count, with the floor beingmax(App Store Connect, project.pbxproj), and the local build-seq counter is retiredThe title says "align the version record with the 1.0.<commit_count> scheme" - so this is about aligning things to match that version scheme. The changes include:
I need to provide a precise description focused on functional impact.
Aligns the project with the
1.0.<commit_count>version scheme by retiring the Mac App Store/TestFlight distribution path for CodeCaps for Mac and tightening the documentation of the unified version scheme in the ship script.Changes:
docs/IOS-TESTFLIGHT.md: Renames the Mac section to "CodeCaps For Mac (Retired From TestFlight)" and replaces the active TestFlight/Mac App Store instructions with an owner-ruling note (CC-169) explaining that the Mac app is now distributed solely as a signed, notarized DMG via GitHub Releases. Documents what was removed (the
macos-ship.ymlworkflow and its contract test, the Mac App Store signing and export scripts,mac-appstore-profiles.json, thecodecaps-macentry inapps.json, and the Apple Distribution signing overrides on the Mac targets) and confirms that the Mac targets still compile under Swift CI but are no longer archived or uploaded.ios/CodeCapsCompanion/project.yml: Removes the
Releaseconfiguration overrides (CODE_SIGN_STYLE: Manual,CODE_SIGN_IDENTITY: "Apple Distribution",PROVISIONING_PROFILE_SPECIFIER: "CodeCaps for Mac AppStore"/"CodeCaps Mac Widgets AppStore") from theCodeCapsCompanionMacandCodeCapsWidgetsMactargets, matching the retirement of the Mac App Store ship path.scripts/ios-fleet/ship-testflight.sh: Updates header and in-script comments to correctly describe the commit-count scheme — marketing version
1.0.<commit_count>, build version the same integer, and the floor computed asmax(App Store Connect, project.pbxproj). Documents the guard that raises both numbers together when App Store Connect already holds a given commit count. Notes that the local build-seq counter file is retired (kept only as a stub in the vendored script) and is no longer a floor source, and reflects the corresponding removal of thenext_build_seqstep from the pre-gate ordering list.