Commit fa3792e9 authored by intrigeri's avatar intrigeri
Browse files

Release process: automate and document better the version number bumps.

parent d966266c
...@@ -328,7 +328,7 @@ just appeared: ...@@ -328,7 +328,7 @@ just appeared:
After a new Tails release is out After a new Tails release is out
-------------------------------- --------------------------------
If you just put out a final release: ### If you just put out a final release
* [[merge `stable` or `testing` into * [[merge `stable` or `testing` into
`devel`|APT_repository/custom#workflow-merge-main-branch]] `devel`|APT_repository/custom#workflow-merge-main-branch]]
...@@ -356,20 +356,6 @@ If you just put out a final release: ...@@ -356,20 +356,6 @@ If you just put out a final release:
git commit debian/changelog \ git commit debian/changelog \
-m "Add dummy changelog entry for ${NEXT_PLANNED_MINOR_VERSION:?}." -m "Add dummy changelog entry for ${NEXT_PLANNED_MINOR_VERSION:?}."
If you just released a RC (XXX: please automate these steps during the
3.2~rc1 release process, based on the above commands):
* add a dummy changelog entry (for the upcoming, non-RC version) in
the branch used for the release (`stable` or `testing`), so that the
next builds from it do not use the APT suite meant for the RC
* add a dummy changelog entry (for the release *after* the one you
released a RC for) in the branch used for the release (`stable` or
`testing`), so that the next builds from it do not use the APT suite
meant for the RC (XXX: I don't understand what this is about; is it
instead about adding an entry for that release on the `devel`
branch? -- intrigeri)
If the release was a major one, then: If the release was a major one, then:
1. [[Hard reset the stable APT suite to 1. [[Hard reset the stable APT suite to
...@@ -382,6 +368,30 @@ If the release was a major one, then: ...@@ -382,6 +368,30 @@ If the release was a major one, then:
git commit config/APT_overlays.d/ \ git commit config/APT_overlays.d/ \
-m "Empty the list of APT overlays: they were merged" -m "Empty the list of APT overlays: they were merged"
### Else, if you just released a RC
* increment the version number in `debian/changelog` on the branch
used for the release, to match the upcoming non-RC release, so that
the next builds from it do not use the APT suite meant for the RC:
cd "${RELEASE_CHECKOUT}" && \
git checkout "${RELEASE_BRANCH:?}" && \
dch --newversion "${NEXT_PLANNED_MAJOR_VERSION:?}" \
"Dummy entry for next release." && \
git commit debian/changelog \
-m "Add dummy changelog entry for ${NEXT_PLANNED_MAJOR_VERSION:?}."
* increment the version number in `devel`'s `debian/changelog` to
match the second next major release, so that images built from there
have the right version number:
cd "${RELEASE_CHECKOUT}" && \
git checkout devel && \
dch --newversion "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}" \
"Dummy entry for next release." && \
git commit debian/changelog \
-m "Add dummy changelog entry for ${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}."
Giving access to a core developer Giving access to a core developer
--------------------------------- ---------------------------------
......
...@@ -40,7 +40,14 @@ the scripts snippets found on this page: ...@@ -40,7 +40,14 @@ the scripts snippets found on this page:
* `NEXT_PLANNED_VERSION`: set to the version number of the next Tails release * `NEXT_PLANNED_VERSION`: set to the version number of the next Tails release
(e.g. 0.23 when releasing 0.22.1, and 1.3 when releasing 1.2) (e.g. 0.23 when releasing 0.22.1, and 1.3 when releasing 1.2)
* `NEXT_PLANNED_MAJOR_VERSION`: set to the version number of the next * `NEXT_PLANNED_MAJOR_VERSION`: set to the version number of the next
*major* Tails release *major* Tails release; if you're preparing a RC for a major release,
use that major release; otherwise, use whatever the next planned
major release is
* `SECOND_NEXT_PLANNED_MAJOR_VERSION`: set to the version number of
the second next *major* Tails release; e.g. if preparing the RC for
the 3.9 major release, then set this to 3.12 (3.9 is the next major
release, 3.10 and 3.11 are bugfix releases, 3.12 is a major
release).
* `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next * `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next
*minor* Tails release; if the next release is a point-release, use *minor* Tails release; if the next release is a point-release, use
that one; otherwise, use `${VERSION}.1` that one; otherwise, use `${VERSION}.1`
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment