Bug #16572
release_process: please clarify expectations for further versions
0%
Description
Right now we have the following variables:
* `NEXT_PLANNED_MAJOR_VERSION`: set to the version number of the next
*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_BUGFIX_VERSION`: set to the version number of the next
*bugfix* Tails release; if the next release is a bugfix release, use
that one; otherwise, use `${VERSION}.1`
* `NEXT_POTENTIAL_EMERGENCY_VERSION`: set to the version number we'll give
to the next emergency release if we have to put one outwhich are used as follows:
if [ "${DIST:?}" = stable ]; then
echo \
--next-version "${NEXT_PLANNED_MAJOR_VERSION:?}" \
--next-version "${NEXT_PLANNED_MAJOR_VERSION:?}~rc1" \
--next-version "${NEXT_PLANNED_BUGFIX_VERSION:?}" \
--next-version "${NEXT_POTENTIAL_EMERGENCY_VERSION:?}" \
else
echo --next-version $(echo ${VERSION:?} | sed -e 's,~.*$,,')
fiSECOND_NEXT_PLANNED_MAJOR_VERSION isn’t used as an argument for --next-version and is only used in wiki/src/contribute/APT_repository/custom.mdwn in the “You’ve just released an RC” case. It seems to only make sense to set it when an RC is being prepared. Right now, it’s a little hard to imagine what that could look like anyway, as the only major release planned right now is “3.17 or 4.0”…
Back to the other ones. We have --next-version for the next major and its RC, the next planned bugfix version, and the possible emergency release for the current version. When preparing 3.13, should we really be --next-version-ing for 3.17, 3.17~rc1, 3.14, and 3.13.1? It seems to me going for 3.14, 3.15 (next two planned releases, whatever the type), and 3.13.1 would make more sense. That’s what I’ll be committing shortly. I’m also fixing extra upgrade-description files for 3.14~rc1 which shouldn’t have been added to begin with.
Subtasks
History
#1 Updated by intrigeri 2019-03-19 10:07:49
- Assignee set to CyrilBrulebois
>
> if [ "${DIST:?}" = stable ]; then
> echo \
> --next-version "${NEXT_PLANNED_MAJOR_VERSION:?}" \
> --next-version "${NEXT_PLANNED_MAJOR_VERSION:?}~rc1" \
> --next-version "${NEXT_PLANNED_BUGFIX_VERSION:?}" \
> --next-version "${NEXT_POTENTIAL_EMERGENCY_VERSION:?}" \
> else
> echo --next-version $(echo ${VERSION:?} | sed -e 's,~.*$,,')
> fi
> > SECOND_NEXT_PLANNED_MAJOR_VERSION isn’t used as an argument for --next-version and is only used in wiki/src/contribute/APT_repository/custom.mdwn in the “You’ve just released an RC” case. It seems to only make sense to set it when an RC is being prepared. Right now, it’s a little hard to imagine what that could look like anyway, as the only major release planned right now is “3.17 or 4.0”…
Indeed. And the code you quoted only uses it for non-RC’s. So I would update the “environment” part to make it clear the RM only needs to set that when preparing a RC.
Will you do so?
> Back to the other ones. We have --next-version for the next major and its RC, the next planned bugfix version, and the possible emergency release for the current version. When preparing 3.13, should we really be --next-version-ing for 3.17, 3.17~rc1, 3.14, and 3.13.1? It seems to me going for 3.14, 3.15 (next two planned releases, whatever the type), and 3.13.1 would make more sense. That’s what I’ll be committing shortly. I’m also fixing extra upgrade-description files for 3.14~rc1 which shouldn’t have been added to begin with.
tl;dr: for 3.13, go for what you did already; for next time, read what follows.
It all depends on what version our devel branch says it is about.
Technically, devel should have a dummy changelog entry about 3.17, and then we do want UDFs for 3.17 and 3.17~rc1, i.e. the current doc & code are correct. I’ve seen developers fork branches for 3.13 off devel last week. Presumably they would have realized their mistake themselves if the resulting ISO they built had “3.17” in its name, and not “3.13” as is the case now.
But right now devel says it’s about 3.13 and IIRC I told you during the last release process that it was OK (I didn’t want us to have a potentially complicated discussion in the heat of a release process). Given you’ve reached “Done with OpenPGP signing” already so for this release, so it’s too late to add new UDFs ⇒ let’s go for what you did and pretend that devel is material for 3.14. No big deal, we can fix that when we release 3.13.1 or 3.14 :)
#2 Updated by intrigeri 2019-09-07 10:18:20
- Status changed from Confirmed to Resolved
intrigeri wrote:
> > SECOND_NEXT_PLANNED_MAJOR_VERSION isn’t used as an argument for --next-version and is only used in wiki/src/contribute/APT_repository/custom.mdwn in the “You’ve just released an RC” case. It seems to only make sense to set it when an RC is being prepared. Right now, it’s a little hard to imagine what that could look like anyway, as the only major release planned right now is “3.17 or 4.0”…
>
> Indeed. And the code you quoted only uses it for non-RC’s. So I would update the “environment” part to make it clear the RM only needs to set that when preparing a RC.
> Will you do so?
I did that in commit:dd14b7789b63152d00352e1e891a01c25b14d0d1 while I was working on Bug #16600.
Regarding the rest of this ticket, I’ve already clarified that the updated doc was correct and explained the consequences of deviating from it in this area.
So AFAICT we’re done here :)