Support for the dedicated release branch flow

[arazabishov]

Challenges

The current bumping flow of the Beachball introduces a few challenges:

• Potential inconsistency between versions on the master, and artifacts published to NPM.
• Code reverts require manually created change files

Potential inconsistency

The process of version bumping in Beachball is not atomic, creating the possibility of inconsistency between versioning on master/dev branches and artifacts published to NPM. In relatively small repositories that are quick to build are not as prone to this issue as larger mono repositories that take more than an hour to build.

For example, if a PR is submitted to master shortly after beachball publish is executed, the PR may be merged with the master before the version update from Beachball. This results in a state, where the artifacts published to NPM do not correspond to any commit on master.

Proposal

Introduce a master/dev branch and a release branch. All PRs are supposed to target the dev branch. Beachball will merge changes from the dev branch to the release branch and update versions in the process. Versions are only maintained on the release branch, including the changelog files. Only one Beachball merge process can be executed at a time. Artifacts are built and released based on the release branch only.

cc: @khovik, @VincentBailly, @bweggersen

[kenotron]

Steps

Here are steps in the release build job:

1. git merge --no-commit master
2. bump (changes changelog, package.json)
3. git add .
4. git merge --continue
5. do BUILD / TEST, whatever
6. beachball publish to npm, pushes package.json changes back into RELEASE branch

Discussion Topics

• whether beachball should get in the business of helping you merge in changes from master into the release branch as outlined in steps 1-4

Estimated Work (if yes on discussion point)

• create a merge + bump command
• any publish command changes needed to push back to release rather than master

[arazabishov]

Thanks for the response @kenotron . After taking a closer look at the implementation steps at Midgard together with @bweggersen, we have realized that a few intermediate implementation steps are missing in the proposal:

1. When merging dev/master into the rolling release branch, beachball needs to use only those change files that have been added since the last bump. This is necessary because dev/master is going to accumulate change files indefinitely. The API might look something like: beachball bump --since <REF>.
2. Ability to run publish without executing bump and revert, i.e. steps 1, 2, and 8 from the publish documentation.