-
Notifications
You must be signed in to change notification settings - Fork 0
Versioning Strategy
The following applies to all Daf repos.
Daf development pretty much sticks to GitHub Flow with optional release servicing branches.
The master branch reflects stable code that is, or can be, deployed to production.
Version numbers follow SemVer2, with git release tags having a v prefix. Prerelease commits, at least currently, don't get tagged. Prerelease executables/releases are to be built with an -alpha suffix. This can be done by adding -alpha to the version property in the version.json file found in each repo's root directory. All builds happening outside of master and the release servicing branches are appended with a commit id suffix matching gits short hash, such as 1.5.2-gabc1234. A preview build might look something like 1.6.0-alpha-gabc1234.
The major version is bumped for API-breaking releases, minor for new functionality and patch every time the git height changes. The exception is 0.* builds, where we instead bump minor for API-breaking releases and push new functionality as patch bumps instead. Version 1 doesn't get released until the API is stable.
Development is typically done in branches starting with feature/* or fix/*. These branches are based off of master and merged back into master for speedy deployment when considered stable. They should ideally be deployed to production and verified there before being merged into master, so that a rollback can be performed easily by re-deploying master.
PRs merged into master with the create-release label set will tag the commit and create a release. Not all PRs need to have a release created; sometimes it's unnecessary, such as when performing code cleanup, optimizations or dependency updates. PRs that increment the major or minor version need to do so by modifying version.json in that repo's root directory.
If the need for a long-lived "next version"-branch is required, the development branch can be created and used. If the need to push preview releases from this branch arises, changes will likely need to be made to the release/publish workflows. They currently only create releases from stable (master and release/* branches) builds. However, they can still push preview nuget packages from the development branch.
Release (naming standard: release/*) branches are not created every time master gets a major or minor version bump. They should only be created when it is necessary to release updates to previous major or minor releases. They should be based off the last master commit before the version was bumped, and they should follow the branch naming standard. This will allow for stable releases to be pushed from these branches.
Every time a release is created, the commit resulting in the release is tagged with a version tag in the format of v{major.minor.patch}. Two "moving tags" are also created: v{major} and v{major.minor}. These two tags will be moved to the latest matching release commit, as new releases are created.