Skip to content

Minor fix to alpha versions in version scheme doc #1143

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 13, 2023
Merged

Minor fix to alpha versions in version scheme doc #1143

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion docs/contributors/version_scheme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@ This page describes FireFly's versioning scheme
---

## Semantic versioning

FireFly follows [semantic versioning](https://semver.org/). In summary, this means:

Given a version number MAJOR.MINOR.PATCH, increment the:
Expand All @@ -32,7 +33,9 @@ Given a version number MAJOR.MINOR.PATCH, increment the:
When creating a new release, the release name and tag should be the semantic version should be prefixed with a `v` . For example, a certain release name/tag could be `v0.9.0`.

## Pre-release test versions

For pre-release versions for testing, we append a date and index to the end of the most recently released version. For example, if we needed to create a pre-release based on `v0.9.0` and today's date is October 22, 2021, the version name/tag would be: `v0.9.0-20211022-01`. If for some reason you needed to create another pre-release version in the same day (hey, stuff happens), the name/tag for that one would be `v0.9.0-20211022-02`.

## Candidate releases
For pre-releases that are candidates to become a new major or minor release, the release name/tag will be based on the release that the candidate *will become* (as opposed to the test releases above, which are based on the previous release). For example, if the current latest release is `v0.9.0` but we want to create an alpha release for 1.0, the release name/tag would be `v1.0.0-alpha-01`.

For pre-releases that are candidates to become a new major or minor release, the release name/tag will be based on the release that the candidate _will become_ (as opposed to the test releases above, which are based on the previous release). For example, if the current latest release is `v0.9.0` but we want to create an alpha release for 1.0, the release name/tag would be `v1.0.0-alpha.1`.