3rd-party/catch2
1
0
Fork 0
mirror of https://github.com/catchorg/Catch2.git synced 2024-11-22 13:26:10 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update the release process documentation

Browse Source
This commit is contained in:
Martin Hořeňovský 2018-11-26 20:41:14 +01:00
parent df019cc113
commit 16656c4c9e
No known key found for this signature in database
GPG Key ID: DE48307B8B0D381A
1 changed files with 7 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/release-process.md
View File

@ -8,11 +8,11 @@ When enough changes have accumulated, it is time to release new version of Catch
These steps are necessary and have to be performed before each new release. They serve to make sure that the new release is correct and linked-to from the standard places. These steps are necessary and have to be performed before each new release. They serve to make sure that the new release is correct and linked-to from the standard places.
### Approval testing ### Testing
Catch's releases are primarily validated against output from previous release, stored in `projects/SelfTest/Baselines`. To validate current sources, build the SelfTest binary and pass it to the `approvalTests.py` script: `approvalTests.py <path/to/SelfTest>`. All of the tests are currently run in our CI setup based on TravisCI and
AppVeyor. As long as the last commit tested green, the release can
There should be no differences, as Approval tests should be updated when changes to Catch are made, but if there are, then they need to be manually reviewed and either approved (using `approve.py`) or Catch requires other fixes. proceed.
### Incrementing version number ### Incrementing version number
@ -27,7 +27,7 @@ version numbers everywhere and pushing the new version to Wandbox.
### Release notes ### Release notes
Once a release is ready, release notes need to be written. They should summarize changes done since last release. For rough idea of expected notes see previous releases. Once written, release notes should be placed in `docs/release-notes.md`. Once a release is ready, release notes need to be written. They should summarize changes done since last release. For rough idea of expected notes see previous releases. Once written, release notes should be added to `docs/release-notes.md`.
### Commit and push update to GitHub ### Commit and push update to GitHub
@ -46,9 +46,5 @@ it should use linux line endings. All non-bundled reporters (Automake,
TAP, TeamCity) should also be attached as binaries, as they might be TAP, TeamCity) should also be attached as binaries, as they might be
dependent on a specific version of the single-include header. dependent on a specific version of the single-include header.
Since 2.5.0 the released "binaries" (headers) should be PGP signed. Since 2.5.0, the release tag and the "binaries" (headers) should be PGP
signed.
## Optional steps
Because Catch2's [vcpkg](https://github.com/Microsoft/vcpkg) port updates
itself automagically, there are no optional steps at this time.