Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ForbesLindesay/5c2abcfa291aa7f8568be2621cc893ca to your computer and use it in GitHub Desktop.
Save ForbesLindesay/5c2abcfa291aa7f8568be2621cc893ca to your computer and use it in GitHub Desktop.

There are now 3 modes for versioning

  • UNAMBIGUOUS - This is the default now, it will succeed only if it would make no difference which of the other two modes you chose. If the other two modes would have different outcomes, it will fail the release and force you to specify a mode.
  • ALWAYS_INCREASING - This mode is best for publishing applications, it also most closely resembles the behaviour of Rolling Versions before this change. It will treat the maximum published version as the current version, regardless of which branch you are releasing from. This means that each new release is guaranteed to have a higher version number than the previous release.
  • BY_BRANCH - This mode can be useful for libraries. It allows you to create separate branches for different major versions, and release patches to old major versions. When determining the current version, it will only consider git tags/versions that were released on the current branch. This makes it possible to release 1.0.1 after having already released 2.0.0.

If you are using custom scripts to publish your package, you can add the following to the top section of your rolling-package.toml file:

versioning = "ALWAYS_INCREASING"

If you are using npm packages, you can add the following to your package.json file:

"@rollingversions/versioning": "ALWAYS_INCREASING"

There is also a new flag for --allow-any-branch as an alternative to passing the currrent branch name in the --deploy-branch parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment