Canvas Kit supports three branch lines for a current major release, previous major release, and the next upcoming major release. Example release numbers will assume a current major release of 2.0.
- support: The last major support branch (i.e. 1.0). This branch only accepts fixes and will release patch versions with every commit.
- master: The current major support branch (i.e. 2.0). This branch only accepts fixes and will release patch versions with every commit.
- prerelease/minor: The current major feature branch (i.e. 2.1). This branch accepts features and fixes and will release minor versions every 3 weeks.
- prerelease/major: The next major branch (i.e. 3.0). This branch accepts breaking changes, features, and fixes and will release major versions every 6 months. In addition, a release of this branch will advance the "major" of other branches by +1.
Canvas Kit releases two major releases a year, but even and odd releases contain different types of breaking changes.
- even number releases contain minor breaking changes and no visual changes. Most breaking changes can be fixed automatically by using our codemod package.
- odd number releases can contain major breaking changes and can contain visual breaking changes. Many breaking changes can be fixed via a codemod, but a codemod is not guaranteed for every change.
Canvas Kit supports multiple major releases via fast-forward merges. A fast-forward merge allows a high degree of confidence of bug fixes and features. For example, Github will list all the branches and tags a commit exists (i.e. support
, master
, v1.0
). Back-porting commits via cherry-picking create new commit which bypasses this git feature.
Here is the following fast-forward merge direction.
- support -> master
- master -> prerelease/minor
- prerelease/minor -> prerelease/major
This means any commit in support
will also exist in the commit history of master
all the way up to prerelease/major
Pull request branches should exist on a fork of the Canvas Kit repository and not on the main repository. This keeps the branch list clean and ensures the core maintainers experience is as close to the experience of all contributors as much as possible.
Bugs should be fixed in the lowest number support branch where the bug exists. For example, if a bug is present in the support
, master
, prerelease/minor
, and prerelease/major
, the target branch should be support
. The fast-forward merge strategy of Canvas Kit will guarantee the fix will be forward-applied to the rest of the branches.
If a bug exists only in prerelease/major
, the target branch should be prerelease/major
.
All commits to support
and master
are automatically released via automation. prerelease/minor
and prerelease/major
are manually released by the core maintainers.