mirror/PowerToys
1
0
Fork 0
mirror of https://github.com/microsoft/PowerToys.git synced 2024-11-27 14:59:16 +08:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Updated Versioning (markdown)

Clint Rutkas 2020-11-16 17:36:51 -08:00
parent c1f0479c33
commit 2d5afcbcae
1 changed files with 15 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
Versioning.md

@ -18,7 +18,7 @@ We will stick to terminology used by both GitHub and what the APIs provide.
### Release definition
GitHub uses the term `Release` and `Pre-release`. A `release` build is deemed what we are calling a stable quality build while `pre-release` will suite experiemental and release candidate work.
GitHub uses the term `Release` and `Pre-release`. A `release` build is deemed what we are calling a stable quality build while `pre-release` will suite experimental and release candidate work.
### Release Channel
@ -30,7 +30,7 @@ Depending on your channel, that is what software updates you'll get. If you are
### Tagging
GitHub does allow each release to be tagged. This can follow a pre-defined format that we can use to aid us in doing different release channels. Example `v0.0.1-VideoConference` could represent the Video conference experiemental feature.
GitHub does allow each release to be tagged. This can follow a pre-defined format that we can use to aid us in doing different release channels. Example `v0.0.1-VideoConference` could represent the Video conference experimental feature.
This tag will also be appended to the title and systray of PowerToys. (This work has **not** been done yet)
@ -49,16 +49,23 @@ Our software includes .NET based software, we need to adhere to the versioning c
PowerToys will follow the 0.*minor*[.*build*] format currently.
## Matrix of everything
### Suggested versioning structure
Once the update train code is able to parse the tags, we will be able to do more complex releases styles.
- Experimental branches will be versioned based on the release they were based off of.
- At no time can two releases ever have the same release number. Example v0.29.5 and v0.29.5-AwesomeNewFeature.
## Matrix
This would be a breakdown of the 0.29 release and defining code around it.
| Channel | GitHub release type | Tag | Example tag | Defining attribute | Releases on GitHub | Branch |
|---|---|---|---|---|---|---|
| Stable | Release | none | v0.28.5 | What is currently in production. Note how it is a higher build number than Beta. | Yes | Stable |
| Beta | Pre-release | Beta | v0.28.2-Beta | This is a release candidate for stable. This branch will be the base for Stable. | Planned | Beta |
| Dev | Pre-release | Dev | v0.28.2-Dev | Active main development branch. This branch will be the base for Beta. | No | Master |
| Experimental Feature | Pre-release | Experimental | v0.28.2-Experiemental | Testing out a concept we don't fully know if it will make it into PowerToys | Yes | Feature/AwesomeNewFeature |
| Stable | Release | none | v0.29.5 | What is currently in production. Note how it is a higher build number than Beta. | Yes | Stable |
| Beta | Pre-release | Beta | v0.29.2-Beta | This is a release candidate for stable. This branch will be the base for Stable. | Planned | Beta |
| Dev | none | none | v0.0.1| Active main development branch. This branch will be the base for Beta. | No | Master |
| Experimental Feature | Pre-release | Experimental | v0.28.3-Experiemental or v0.28.3-AwesomeNewFeature | Testing out a concept we don't fully know if it will make it into PowerToys | Yes | Feature/AwesomeNewFeature |
## Setting Versions.prop
@ -68,23 +75,13 @@ This would be a breakdown of the 0.29 release and defining code around it.
The application version will be **v0.0.1** for local development. PowerToys will not actively check for a new version if it is `v0.0.1` on start to not cause unneeded notifications.
## Beta builds
These are builds we're testing actively for the upcoming release. The last beta release should be the same code base as the stable with the exception of the build number.
## Building Signed versions
We build the main development branch every day at noon. This will allow us to know if we have a build breaking issue. These since these will continue to be built against `v0.0.1`, even when we test a build, it won't impact our ability to see crashes for a public release. We can test against these internally without an issue and won't cause any issue for what build is what. When have a confirmed commit we want a signed build from, we will bring have the `Stable` branch based against this and set the variable in the pipeline to have a pre-build event actually set the version number in `Versions.prop`. This will make the only item able to set the file be on the farm.
We will increase the *build* number for any hot fix that goes into Stable, including if that is before a public release. This directly implies we could release a `v0.15.2` without the public ever seeing a `v0.15.0` or `v0.15.1` due to finding a last minute critical bug.
### Signed branches
- `Stable` – This is the branch we release our main release from. We will use tags to inform version number to the public which is what we already do currently.
- `Beta` – This will the branch we release our main release from. We will use tags to inform version number to the public which is what we already do currently.
- Experimental / Feature Branches - This will be the branch where we release pre-release variants of PowerToys. Once we hit stability, this will be how
we do share prerelease builds to the public so we have a known stable build for everyone.
- We will do a full minor increase. This means if the current major release is `v0.10.0`, this would be `v0.11.0` and the next major release would be `v0.12.0`
We will only release signed builds to the channels.
## Open questions