Bit: Adding pre-release support for `bit tag`

[itaymendel]

As it stands, Bit does not support semver's pre-release feature. It should support it, as using pre-release developers can share pre-production changes for components and check for their compatibility in other projects.

Goal of pre-release

pre-release aims to define an unstable version of a component. meaning that before I publish 1.0.0 I will publish 1.0.0-alpha.1. This way consumers will know to which version the upcoming changes will be published to.

Setting a pre-release version

Specify a version with a pre-release.

A developer should be able to add a semver pre-release with tagging a specific version for a component.

[email protected]
$ bit tag -a 1.0.0-alpha
[email protected]

Add --pre-release when bumping a component version

When a developer modifies a component and wants to publish it as an upcoming change to the next version, they should add the --pre-release option to the bit tag command. This option works alongside the current version-bump mechanism as implemented by the --major, --minor, and --patch options.

For example, a developer has [email protected] modified:

# By default, Bit does a patch bump. when `--pre-release` is added, pre-release is for a patch change.
$ bit tag --pre-release
[email protected]

# The developer wants to set a pre-release version of a patch update.
$ bit tag --pre-release --patch
[email protected]

# The developer wants to set a pre-release version of a minor update
$ bit tag --pre-release --minor
[email protected]

The developer wants to set a pre-release version of a major update.
$ bit tag --pre-release --major
[email protected]

Named pre-release

By default Bit names pre-release version alpha. The --pre-release option can get a string value of the pre-release name.

[email protected]
$ bit tag --pre-release next
[email protected]

Dependents and pre-releases

auto-tag for dependents

In case there are components in a workspace depending on a component that is tagged with a pre-release they will be auto-tagged with a --patch --pre-release as well.

tagging a version that depends on a pre-release

When bit tag tries to tag a component with a release, but that version will depend on a pre-released component, prompt a warning saying:

warning - <component A> version <componentA next-version> will depend on a pre-release version of <comp B> - <pre-release of comp B>

Bit should be able to allow a release to depend on a pre-release, just add a warning.

incrementing pre-released versions

As long as the --pre-release option is set, the next version bump with be of a pre-release. If a component is already tagged with a pre-release, Bit increments that pre-release. Bit should keep the same pre-release name unless stated otherwise.

# keep the same pre-release name
[email protected]
bit tag --pre-release
[email protected]

# update pre-release name
[email protected]
bit tag --pre-release beta
[email protected]

# set the pre-release to a different actual release
[email protected]
bit tag --pre-release --major
[email protected]

transform a pre-release to a release

When running bit tag without the --pre-release option, Bit transforms all pre-releases to actual releases.

# without specify the next version-bump use the semver in the pre-release
[email protected]
bit tag
[email protected]

# specify the version bump
[email protected]
bit tag --minor
[email protected]

In case the version is already taken prompt an error saying "unable to set a version" and ask the user to specify the version bump they require to do.

Version precedence

There are several commands in Bit that care about version precedence

• bit import
• bit checkout
• bit list
• bit show
• bit merge

From semver.org

1. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order.
2. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
3. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0.

Apply version precedence rules to Bit commands

1. When import | checkout | merge occurs on a component, Bit should NOT give precedence to pre-releases.
2. When list shows data from a remote collection, don't give precedence to pre-releases on the remote.
3. When show shows data from a remote component, don't give precedence to pre-releases on the remote.

Add --include-pre-releases option to Bit commands

All commands that handle version precedence should have the option to set precedence to pre-released versions. This way, when a user uses these commands with the --include-pre-releases flag, and a pre-release is in fact the "latest" version, it should "break" the semver-precedence rules and treat the latest pre-release precedence.

This is helpful for several cases:

1. This way when a developer wants to checkout, import or merge the latest pre-release, they can, without asking for the specific pre-release version.
2. When listing all components in a scope, Bit will show pre-releases for components, if available.

[GiladShoham]

@itaymendel

few comments:

1. better to use NAME.1 instead of NAME-1
2. we should add flags to list / show to also show pre-release versions
3. we should add flag about pre-release for bit checkout as well

questions:

1. What happens if my component is at 2.0.0-pre.1 and I tag using --minor what should be the version? 2.0.1-pre.1? error?
2. what happens if I have a component b with dependent a. I'm now tagging b with pre-release. a will have an auto-tag which makes a's new (regular) version to be dependent upon b's pre-release.

[itaymendel]

@GiladShoham @davidfirst i refactored the specification, please review and comment.
The goal is to keep a pre-release BEFORE setting the actual release on that version. IE - [email protected] should be published prior to [email protected], as it is its BETA version for 1.0.0.

[ruscon]

our company would like to use bit.dev, but without this feature, it is simply impossible

[GiladShoham]

@ruscon We plan to start working on this very soon. We don't have an ETA yet.