feat: let a release history entry set its own minimumBackgroundDuration - #199
Merged
floyd-soomgo merged 9 commits intoSep 17, 2026
Merged
Conversation
A release can now carry `minimumBackgroundDuration`, which wins over the one the `sync` call passes, so a single release can be applied sooner or later than the app asks for by default.
`release --minimum-background-duration <seconds>` writes the value on the release history entry it creates, so the release decides its own background wait instead of taking the one the `sync` call passes. Without the option the entry says nothing about it, exactly as before.
…unt --rollout as an option `update-history --minimum-background-duration <seconds>` edits the background wait of a release that is already out, which is how a team lowers it to 0 once the release has been running for a while. The "no options specified" guard only looked at --mandatory and --enable, so `update-history --rollout 50` exited instead of saving the percentage. It now counts every option that changes the entry.
The release and update-history commands can now set a background wait on a single release, and the runtime prefers it over the minimumBackgroundDuration the sync call passes, so the CLI option list and the JS API reference say so.
floyd-soomgo
marked this pull request as ready for review
September 17, 2026 07:56
floyd-soomgo
deleted the
feature/release-history-minimum-background-duration
branch
September 17, 2026 07:58
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.
Summary
Apps using this fork hardcode the wait in
CodePush.sync({ installMode: ON_NEXT_RESUME, minimumBackgroundDuration: 3600 }), so every update waits the same hour. This lets each release decide for itself.ReleaseInfo) can carryminimumBackgroundDuration(seconds). When present it takes precedence over thesyncoption; when absent thesyncoption applies as before.0is a valid value and means "on the next resume", so the value is resolved with??andtypeof === 'number'checks rather than truthiness.UpdateCheckResponse.minimum_background_duration→RemotePackage.minimumBackgroundDuration→localPackage.install(installMode, minimumBackgroundDuration). The deprecatedupdateCheckerpath goes through the same mapper, so it works there too. Native code is untouched.releaseandupdate-historygain--minimum-background-duration <seconds>(whole number, 0 or greater).update-historyis how a team lowers the wait to0after a release has gone out.update-historyused to exit with "No options specified" when--rolloutwas the only option. Now--rolloutand the new option both count. Since--rolloutcan reach the write path on its own, the command validates it the same wayreleasedoes, plus a finiteness check so--rollout abccannot writenullinto the history.README.md,docs/api-js.md, and the CLI reference incli/README.md/cli/README.ko.md.Verification
npx jest --watchman=false src/CodePush.test.js: 32 tests, including three that assert the value the native bridge receives for a history value, no history value, and a history value of0npm run --workspace cli test: 12 suites, 116 testsnpm run typecheckand ESLint on changed filesnpm run e2e -- --app RN0840 --platform both, iPhone 17 simulator + Galaxy S23 over USB): all phases pass on both platforms, first try. Two new phase-4 scenarios cover the feature end to end:05releases with--minimum-background-duration 0while the app'ssyncasks for 20 seconds and the update is applied on the first resume;06releases with20whilesyncasks for no wait, and the update is not applied after a 2 second background but is after 20 seconds. The runner also asserts the served history entry carries the value.Follow-up
release --rollout abcstill passesNaNthrough its range check (pre-existing). Aligning it with theupdate-historycheck is a one-line change, left out of this PR.