Project

General

Profile

Bug #16572

release_process: please clarify expectations for further versions

Added by CyrilBrulebois 6 months ago. Updated 8 days ago.

Status:
Resolved
Priority:
Normal
Category:
-
Target version:
-
Start date:
03/19/2019
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:
Starter:
Affected tool:

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 out

which 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,~.*$,,')
                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”…

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.

History

#1 Updated by intrigeri 6 months ago

  • 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 8 days ago

  • 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 dd14b7789b63152d00352e1e891a01c25b14d0d1 while I was working on #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 :)

Also available in: Atom PDF