1
0
mirror of https://github.com/vcmi/vcmi.git synced 2024-12-24 22:14:36 +02:00

Update docs according to review

This commit is contained in:
Ivan Savenko 2023-09-17 01:49:17 +03:00
parent 45840a9522
commit 85deaf0b4b

View File

@ -1,10 +1,15 @@
< [Documentation](../Readme.md) / Release Process
# Versioning
For releases VCMI uses version numbering in form "1.X.Y", where:
- 'X' indicates major release. Different major versions are generally not compatible with each other. Save format is different, network protocol is different, mod format likely different.
- 'Y' indicates hotfix release. Despite its name this is usually not urgent, but planned release. Different hotfixes for same major version are fully compatible with each other.
# Branches
Our branching strategy is very similar to GitFlow
- `master` branch has release commits. One commit - one release. Each release commit should be tagged with version `maj.min.patch`
- `beta` branch is for stabilization of ongoing release. Only safe changes should be targeted into this branch. Breaking changes (e.g. save format changes) are forbidden in beta.
- `develop` branch is a main branch for ongoing development. Pull requests with new features should be targeted to this branch, `develop` version is one major release ahead of `beta`
Our branching strategy is very similar to GitFlow:
- `master` branch has release commits. One commit - one release. Each release commit should be tagged with version `1.X.Y` when corresponding version is released. State of master branch represents state of latest public release.
- `beta` branch is for stabilization of ongoing release. Beta branch is created when new major release enters stabilization stage and is used for both major release itself as well as for subsequent hotfixes. Only changes that are safe, have minimal chance of regressions and improve player experience should be targeted into this branch. Breaking changes (e.g. save format changes) are forbidden in beta.
- `develop` branch is a main branch for ongoing development. Pull requests with new features should be targeted to this branch, `develop` version is one major release ahead of `beta`.
# Release process step-by-step
@ -22,7 +27,7 @@ Should be done 2-4 weeks before planned release date. All major features should
- Bump version for Linux on `develop` branch
- Bump version and build ID for Android on `develop` branch
### Initial release setup (patch releases only)
### Initial release setup (hotfix releases only)
- Bump vcmi version in CMake on `beta` branch
- Bump version for Linux on `beta` branch
@ -44,11 +49,12 @@ Should be done 1 day before release. At this point beta branch is in full freeze
- Merge release preparation PR into `beta`
- Merge `beta` into `master`. This will trigger CI pipeline that will generate release packages
- Create draft release page, specify `1.x.y` as tag for `master` after publishing
- Check that artifacts for all platforms have been build by CI `master` branch
- Check that artifacts for all platforms have been built by CI on `master` branch
- Download and rename all build artifacts to use form "VCMI-1.X.Y-Platform.xxx"
- Attach build artifacts for all platforms to release page
- Manually extract Windows installer, remove `$PLUGINSDIR` directory and repackage data as .zip archive
- Manually extract Windows installer, remove `$PLUGINSDIR` directory which contains installer files and repackage data as .zip archive
- Attach produced zip archive to release page as an alternative Windows installer
- Upload built AAB to Google Play and send it for review
- Upload built AAB to Google Play and send created release draft for review (usually takes several hours)
- Prepare pull request for [vcmi-updates](https://github.com/vcmi/vcmi-updates)
- (major releases only) Prepare pull request with release update for web site https://github.com/vcmi/VCMI.eu