|
1 | 1 | # Uno.Wasm.Bootstrap release procedure
|
2 | 2 |
|
3 |
| -Uno.Wasm.Bootstrap uses [GitVersion](https://gitversion.readthedocs.io/en/latest/) for its versioning, in `mainline` mode for the `release/stable` branches, and **ContinuousDeployment** for the `master` branch. |
| 3 | +Uno.Wasm.Bootstrap uses [NBGV](https://github.com/dotnet/nbgv) for its versioning. |
4 | 4 |
|
5 | 5 | Tagging is the main driver for planning releases.
|
6 | 6 |
|
7 | 7 | ## Branches
|
8 | 8 |
|
9 |
| -- On the `master` branch, the main development is happening and is considered unstable. The nuget packages produced end with `-dev.X`, where X is the number of commits since the last initiated release. |
10 |
| -- On the `release/beta` branch, stabilization occurs to get a stable release. The version is inherited from the branch point from master. The nuget packages produced end with `-beta.X`, where X is the number of commits since the last stable release. |
| 9 | +- On the `main` branch, the main development is happening and is considered unstable. The nuget packages produced end with `-dev.X`, where X is the number of commits since the last initiated release. |
| 10 | +- On the `release/beta` branch, stabilization occurs to get a stable release. The version is inherited from the branch point from main. The nuget packages produced end with `-beta.X`, where X is the number of commits since the last stable release. |
11 | 11 | - On the `release/stable` branch, stable nuget packages are produced for each pushed merge or commit. The **Patch** number is increased by the number of commits since the release tagging occurred.
|
12 | 12 | - On `dev`, `feature`, and `project` branches, the behavior is to inherit from the base branch it was created from and create a nuget package with an experimental tag. Those branches must not be tagged.
|
13 | 13 |
|
14 | 14 | ## Creating a release
|
15 | 15 |
|
16 | 16 | ### When planning for a beta
|
17 | 17 |
|
18 |
| -- Once a release is planned, make a branch in `release/beta` (e.g. `release/beta/1.29`), and tag the commit using the requested version (e.g. `1.29`). Do not include the patch number, as it will be added by GitHub when publishing a release. Tagging will automatically increased the version in the `master` branch by a **minor** number. |
| 18 | +- Once a release is planned, make a branch in `release/beta` (e.g. `release/beta/1.29`), and tag the commit using the requested version (e.g. `1.29`). Do not include the patch number, as it will be added by GitHub when publishing a release. Tagging will automatically increased the version in the `main` branch by a **minor** number. |
19 | 19 | - Make stabilization fixes to the `release/beta/1.29` branch.
|
20 | 20 | - Once the stabilization fixes are done, take the last `release/beta/1.29` commit and make a `release/stable/1.29` branch. Commits to this branch will automatically keep the `1.29` version, as the base **beta branch** was tagged `1.29`.
|
21 | 21 | - Publish the release on GitHub using the patch number (e.g. `1.29.0` if there where no changes)
|
22 | 22 |
|
23 | 23 | ### When planning for a release without a beta
|
24 | 24 |
|
25 |
| -- Once a release is planned, make a branch in `release/stable` (e.g. `release/stable/1.29`), and tag the commit using the requested version (e.g. `1.29`). Tagging will automatically the version in the `master` increased by a **minor** number. |
| 25 | +- Once a release is planned, make a branch in `release/stable` (e.g. `release/stable/1.29`), and tag the commit using the requested version (e.g. `1.29`). Tagging will automatically the version in the `main` increased by a **minor** number. |
26 | 26 | - Commits to `release/stable/1.29` will automatically keep the `1.29` version.
|
27 | 27 | - Publish the release on GitHub using the patch number (e.g. `1.29.0` if there where no changes)
|
0 commit comments