cros/kron: Support ChromeOS 2-week release cadence (M153+) [infra/infra : main]
See Wai Fu (Gerrit)
See Wai Fu voted and added 1 comment![]( "Open in Gerrit")
Votes added by See Wai Fu
| Auto-Submit | +1 |
| Commit-Queue | +1 |
1 comment
This CL supports change for the new 2-week release cadence. Please review. Thanks.
Related details
- Matt Bubernak
- Prasad Vuppalapu
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Prasad Vuppalapu (Gerrit)
Prasad Vuppalapu added 2 comments![]( "Open in Gerrit")
return milestone > 0 && milestone < GetTot()-3Please fix this WARNING reported by autoreview issue finding: Since `GetStable()` now has dynamic logic for the 2-week cadence, `isLTS` should probably use `GetStable()` instead of `GetTot() - 3`.\n\nWith `GetTot() - 3`, when ToT is an even milestone (e.g., 158), `GetTot() - 3` evaluates to 155. This makes `154 < 155` true, incorrectly classifying the current active Stable (154) as an LTS branch.\n\nPrior to this change, `GetTot() - 3` was exactly equal to `GetStable()`. Updating this to `milestone < GetStable()` maintains the original behavior where LTS milestones are strictly older than the active Stable.
case isNextStable(milestone):Please fix this WARNING reported by autoreview issue finding: Placing `isNextStable` before `isDev` and `isBeta` means that `IdentifyBranch` will shadow these branches. Specifically, it will never return `Branch_DEV` when ToT is odd, and never return `Branch_BETA` when ToT is even (as explicitly asserted in your tests).\n\nIf downstream consumers rely on `IdentifyBranch` to schedule or identify standard `DEV` and `BETA` branches, they will break when they receive `NEXT_STABLE` instead.\n\nIf `NEXT_STABLE` is only meant to be a target alias (e.g. for `IsTargetedBranch`), consider checking it after `isDev` and `isBeta`, or removing it from `IdentifyBranch` entirely so it doesn't mask the standard release channels.
Related details
- Matt Bubernak
- See Wai Fu
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
See Wai Fu (Gerrit)
See Wai Fu voted and added 3 comments![]( "Open in Gerrit")
Votes added by See Wai Fu
| Auto-Submit | +1 |
| Commit-Queue | +1 |
Feedback was addressed. Please review again. Thanks.
Please fix this WARNING reported by autoreview issue finding: Since `GetStable()` now has dynamic logic for the 2-week cadence, `isLTS` should probably use `GetStable()` instead of `GetTot() - 3`.\n\nWith `GetTot() - 3`, when ToT is an even milestone (e.g., 158), `GetTot() - 3` evaluates to 155. This makes `154 < 155` true, incorrectly classifying the current active Stable (154) as an LTS branch.\n\nPrior to this change, `GetTot() - 3` was exactly equal to `GetStable()`. Updating this to `milestone < GetStable()` maintains the original behavior where LTS milestones are strictly older than the active Stable.
Done
Please fix this WARNING reported by autoreview issue finding: Placing `isNextStable` before `isDev` and `isBeta` means that `IdentifyBranch` will shadow these branches. Specifically, it will never return `Branch_DEV` when ToT is odd, and never return `Branch_BETA` when ToT is even (as explicitly asserted in your tests).\n\nIf downstream consumers rely on `IdentifyBranch` to schedule or identify standard `DEV` and `BETA` branches, they will break when they receive `NEXT_STABLE` instead.\n\nIf `NEXT_STABLE` is only meant to be a target alias (e.g. for `IsTargetedBranch`), consider checking it after `isDev` and `isBeta`, or removing it from `IdentifyBranch` entirely so it doesn't mask the standard release channels.
- Matt Bubernak
- Prasad Vuppalapu
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Prasad Vuppalapu (Gerrit)
Prasad Vuppalapu voted![]( "Open in Gerrit")
- Matt Bubernak
- See Wai Fu
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
LUCI CQ (Gerrit)
LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
cros/kron: Support ChromeOS 2-week release cadence (M153+)
Starting from M153, ChromeOS will align with Chrome Browser's bi-weekly
milestone release cycle where only EVEN-numbered milestones are promoted
to Stable.
This implements GetNextStable() and updates GetStable(), isStable(), and
isLTS() in totmanager to handle the dynamic even/odd milestone target
rules. It also adds support for NEXT_STABLE in branch identification
and milestone resolution.
BUG=b:524877490
TEST=go test ./...
- M go/src/infra/cros/cmd/kron/totmanager/totmanager.go
- M go/src/infra/cros/cmd/kron/totmanager/totmanager_test.go
Code-Review: +1 by Prasad Vuppalapu
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |