napcok/calamares
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: update RELEASE.md procedure

Browse Source
This commit is contained in:
Adriaan de Groot 2020-02-11 12:55:53 +01:00
parent 6c0fecd40d
commit dd33cbfa36
1 changed files with 73 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
ci/RELEASE.md
View File

@ -1,17 +1,16 @@
The Calamares release process # Calamares Release Process
=============================
> As releases from *master* are now rolling when-they-are-ready releases, > Calamares releases are now rolling when-they-are-ready releases.
> some of these steps no longer are followed. In particular, -RC releases > Releases are made from *master* and tagged there. When, in future,
> are not done anymore (although the RC variable is set in `CMakeLists.txt` > LTS releases resume, these steps may be edited again.
> to avoid accidents) and most things are automated through the release >
> script [RELEASE.sh](RELEASE.sh) > Most things are automated through the release script [RELEASE.sh](RELEASE.sh)
#### (0) A week in advance ## (0) A week in advance
* (Only releases from master) * Run [Coverity scan][coverity], fix what's relevant. The Coverity scan runs
Run [Coverity scan][coverity], fix what's relevant. The Coverity scan runs automatically once a week on master. The badge is displayed on the
automatically once a week on master. project front page and in the wiki.
* Build with clang -Weverything, fix what's relevant. * Build with clang -Weverything, fix what's relevant.
``` ```
rm -rf build ; mkdir build ; cd build rm -rf build ; mkdir build ; cd build
@ -26,34 +25,69 @@ The Calamares release process
an additional environment variable to be set for some tests, which will an additional environment variable to be set for some tests, which will
destroy an attached disk. This is not always desirable. There are some destroy an attached disk. This is not always desirable. There are some
sample config-files that are empty and which fail the config-tests. sample config-files that are empty and which fail the config-tests.
* (Only releases from master) * Notify [translators][transifex]. In the dashboard there is an *Announcements*
Notify [translators][transifex]. In the dashboard there is an *Announcements* link that you can use to send a translation announcement. Note that regular
link that you can use to send a translation announcement. use of `txpush.sh` will notify translators as well of any changes.
[coverity]: https://scan.coverity.com/projects/calamares-calamares?tab=overview [coverity]: https://scan.coverity.com/projects/calamares-calamares?tab=overview
[transifex]: https://www.transifex.com/calamares/calamares/dashboard/ [transifex]: https://www.transifex.com/calamares/calamares/dashboard/
#### (1) Preparation
* Bump version in `CMakeLists.txt`, *CALAMARES_VERSION* variables, and set ## (1) Preparation
RC to a non-zero value (e.g. doing -rc1, -rc2, ...). Push that.
* Check `README.md` and the [Coding Guide](https://github.com/calamares/calamares/wiki/Develop-Code), make sure it's all still * Pull latest translations from Transifex. We only push / pull translations
relevant. Run `ci/calamaresstyle` to check the C++ code style.
Run pycodestyle on recently-modified Python modules, fix what makes sense.
* Check defaults in `settings.conf` and other configuration files.
* (Only releases from master)
Pull latest translations from Transifex. We only push / pull translations
from master, so longer-lived branches (e.g. 3.1.x) don't get translation from master, so longer-lived branches (e.g. 3.1.x) don't get translation
updates. This is to keep the translation workflow simple. updates. This is to keep the translation workflow simple. The script
automatically commits changes to the translations.
``` ```
sh ci/txpull.sh sh ci/txpull.sh
``` ```
* (Only releases from master) * Update the list of enabled translation languages in `CMakeLists.txt`.
Update the list of enabled translation languages in `CMakeLists.txt`.
Check the [translation site][transifex] for the list of languages with Check the [translation site][transifex] for the list of languages with
fairly complete translations. fairly complete translations, or use `ci/txstats.py` for an automated
suggestion. If there are changes, commit them.
* Push the changes.
* Drop the RC variable to 0 in `CMakeLists.txt`, *CALAMARES_VERSION_RC*.
* Check `README.md` and the
[Coding Guide](https://github.com/calamares/calamares/wiki/Develop-Code),
make sure it's all still
relevant. Run `ci/calamaresstyle` to check the C++ code style.
Run pycodestyle on recently-modified Python modules, fix what makes sense.
* Check defaults in `settings.conf` and other configuration files.
* Edit `CHANGES` and set the date of the release.
* Commit both. This is usually done with commit-message
*Changes: pre-release housekeeping*.
#### (2) Tarball
## (2) Release Day
* Run the helper script `ci/RELEASE.sh` or follow steps below.
The script checks:
- for uncommitted local changes,
- if translations are up-to-date and translators
have had enough time to chase new strings,
- that the build is successful (with gcc and clang, if available),
- tests pass,
- tarball can be created,
- tarball can be signed.
On success, it prints out a suitable signature- and SHA256 blurb
for use in the release announcement.
### (2.1) Buld and Test
* Build with gcc. If available, build again with Clang and double-check
any warnings Clang produces.
* Run the tests; `make test` in the build directory should have no
failures (or if there are, know why they are there).
### (2.2) Tag
* `git tag -s v1.1.0` Make sure the signing key is known in GitHub, so that the
tag is shown as a verified tag. Do not sign -rc tags.
You can use `make show-version` in the build directory to get the right
version number -- this will fail if you didn't follow step (1).
### (2.3) Tarball
* Create tarball: `git-archive-all -v calamares-1.1-rc1.tar.gz` or without * Create tarball: `git-archive-all -v calamares-1.1-rc1.tar.gz` or without
the helper script, the helper script,
@ -64,21 +98,25 @@ The Calamares release process
Double check that the tarball matches the version number. Double check that the tarball matches the version number.
* Test tarball (e.g. unpack somewhere else and run the tests from step 0). * Test tarball (e.g. unpack somewhere else and run the tests from step 0).
#### (3) Tag
* Set RC to zero in `CMakeLists.txt` if this is the actual release. ## (3) Housekeeping
* `git tag -s v1.1.0` Make sure the signing key is known in GitHub, so that the
tag is shown as a verified tag. Do not sign -rc tags.
* Generate MD5 and SHA256 checksums. * Generate MD5 and SHA256 checksums.
* Upload tarball. * Upload tarball.
* Announce on mailing list, notify packagers. * Announce on mailing list, notify packagers.
* Write release article. * Write release article.
#### (4) Release day
* Publish tarball. * Publish tarball.
* Update download page. * Update download page.
* Publish release article on `calamares.io`. * Publish release article on `calamares.io`.
* Publicize on social networks. * Publicize on social networks.
* Close associated milestone on GitHub if this is the actual release. * Close associated milestone on GitHub if this is the actual release.
* Publish blog post. * Publish blog post.
## (4) Post-Release
* Bump the version number in `CMakeLists.txt` in the `project()` command.
* Set *CALAMARES_VERSION_RC* back to 1.
* Add a placeholder entry for the next release in `CHANGES` with date
text *not released yet*.
* Commit and push that, usually with the message
*Changes: post-release housekeeping*.