repo release process

This is the process for creating a new release of repo, as well as all the related topics and flows.

Schedule

There is no specific schedule for when releases are made. Usually it‘s more along the lines of “enough minor changes have been merged”, or "there’s a known issue the maintainers know should get fixed". If you find a fix has been merged for an issue important to you, but hasn't been released after a week or so, feel free to contact us to request a new release.

Release Freezes

We try to observe a regular schedule for when not to release. If something goes wrong, staff need to be active in order to respond quickly & effectively. We also don't want to disrupt non-Google organizations if possible.

We generally follow the rules:

Launcher script

The main repo script serves as a standalone program and is often referred to as the “launcher script”. This makes it easy to copy around and install as you don't have to install any other files from the git repo.

Whenever major changes are made to the launcher script, you should increment the VERSION variable in the launcher itself. At runtime, repo will check this to see if it needs to be updated (and notify the user automatically).

Key management

Every release has a git tag that is signed with a key that repo recognizes. Those keys are hardcoded inside of the repo launcher itself -- look for the KEYRING_VERSION and MAINTAINER_KEYS settings.

Adding new keys to the repo launcher will allow tags to be recognized by new keys, but only people using that updated version will be able to. Since the majority of users will be using an official launcher version, their version will simply ignore any new signed tags.

If you want to add new keys, it's best to register them long ahead of time, and then wait for that updated launcher to make its way out to everyone. Even then, there will be a long tail of users with outdated launchers, so be prepared for people asking questions.

Registering a new key

The process of actually adding a new key is quite simple.

  1. Add the public half of the key to MAINTAINER_KEYS.
  2. Increment KEYRING_VERSION so repo knows it needs to update.
  3. Wait a long time after that version is in a release (~months) before trying to create a new release using those new keys.

Self update algorithm

When creating a new repo checkout with repo init, there are a few options that control how repo finds updates:

  • --repo-url: This tells repo where to clone the full repo project itself. It defaults to the official project (REPO_URL in the launcher script).
  • --repo-rev: This tells repo which branch to use for the full project. It defaults to the stable branch (REPO_REV in the launcher script).

Whenever repo sync is run, repo will, once every 24 hours, see if an update is available. It fetches the latest repo-rev from the repo-url. Then it verifies that the latest commit in the branch has a valid signed tag using git tag -v (which uses gpg). If the tag is valid, then repo will update its internal checkout to it.

If the latest commit doesn't have a signed tag, repo will fall back to the most recent tag it can find (via git describe). If that tag is valid, then repo will warn and use that commit instead.

If that tag cannot be verified, it gives up and forces the user to resolve.

If env variable REPO_SKIP_SELF_UPDATE is defined, this will bypass the self update algorithm.

Force an update

The repo selfupdate command can be used to force an immediate update. It is not subject to the 24 hour limitation.

Branch management

All development happens on the main branch and should generally be stable.

Since the repo launcher defaults to tracking the stable branch, it is not normally updated until a new release is available. If something goes wrong with a new release, an older release can be force pushed and clients will automatically downgrade.

The maint branch is used to track the previous major release of repo. It is not normally meant to be used by people as stable should be good enough. Once a new major release is pushed to the stable branch, then the previous major release can be pushed to maint. For example, when stable moves from v1.10.x to v1.11.x, then the maint branch will be updated from v1.9.x to v1.10.x.

We don‘t have parallel release branches/series. Typically all tags are made against the main branch and then pushed to the stable branch to make it available to the rest of the world. Since repo doesn’t typically see a lot of changes, this tends to be OK.

Creating a new release

When you want to create a new release, you‘ll need to select a good version and create a signed tag using a key registered in repo itself. Typically we just tag the latest version of the main branch. The tag could be pushed now, but it won’t be used by clients normally (since the default repo-rev setting is stable). This would allow some early testing on systems who explicitly select main.

Creating a signed tag

Lets assume your keys live in a dedicated directory, e.g. ~/.gnupg/repo/.

If you need access to the official keys, check out the internal documentation at go/repo-release. Note that only official maintainers of repo will have access as it describes internal processes for accessing the restricted keys.
# Pick the new version.
$ t=v2.30

# Create a new signed tag with the current HEAD.
$ ./release/sign-tag.py $t

# Verify the signed tag.
$ git show $t

Push the new release

Once you're ready to make the release available to everyone, push it to the stable branch.

Make sure you never push the tag itself to the stable branch! Only push the commit -- note the use of ^0 below.

$ git push https://gerrit-review.googlesource.com/git-repo $t
$ git push https://gerrit-review.googlesource.com/git-repo $t^0:stable

If something goes horribly wrong, you can force push the previous version to the stable branch and people should automatically recover. Again, make sure you never push the tag itself!

$ oldrev="whatever-old-commit"
$ git push https://gerrit-review.googlesource.com/git-repo $oldrev:stable --force

Announce the release

Once you do push a new release to stable, make sure to announce it on the repo-discuss@googlegroups.com group. Here is an example announcement.

You can create a short changelog using the command:

# If you haven't pushed to the stable branch yet, you can use origin/stable.
# If you have pushed, change origin/stable to the previous release tag.
# This assumes "main" is the current tagged release.  If it's newer, change it
# to the current release tag too.
$ git log --format="%h (%aN) %s" --no-merges origin/stable..main

Project References

Here's a table showing the relationship of major tools, their EOL dates, and their status in Ubuntu & Debian. Those distros tend to be good indicators of how long we need to support things.

Things in bold indicate stuff to take note of, but does not guarantee that we still support them. Things in italics are things we used to care about but probably don't anymore.

DateEOLGitPythonSSHUbuntu / DebianGitPythonSSH
Apr 20085.0
Jun 20085.1
Oct 2008Oct 20132.6.010.04 Lucid - 10.10 Maverick / Squeeze
Dec 2008Feb 20093.0.0
Feb 20095.2
Feb 2009Mar 2012Debian 5 Lenny1.5.6.52.5.2
Jun 2009Jun 20163.1.010.04 Lucid - 10.10 Maverick / Squeeze
Sep 20095.310.04 Lucid
Feb 2010Oct 20121.7.010.04 Lucid - 12.04 Precise - 12.10 Quantal
Mar 20105.4
Apr 20105.510.10 Maverick
Apr 2010Apr 201510.04 Lucid1.7.0.42.6.5 3.1.25.3
Jul 2010Dec 20192.7.011.04 Natty -
Aug 20105.6
Oct 201010.10 Maverick1.7.12.6.6 3.1.35.5
Jan 20115.7
Feb 20115.811.04 Natty
Feb 2011Feb 2016Debian 6 Squeeze1.7.2.52.6.6 3.1.3
Apr 201111.04 Natty1.7.42.7.1 3.2.05.8
Sep 20115.912.04 Precise
Oct 2011Feb 20163.2.011.04 Natty - 12.10 Quantal
Oct 201111.10 Ocelot1.7.5.42.7.2 3.2.25.8
Apr 20126.012.10 Quantal
Apr 2012Apr 201912.04 Precise1.7.9.52.7.3 3.2.35.9
Aug 20126.113.04 Raring
Sep 2012Sep 20173.3.013.04 Raring - 13.10 Saucy
Oct 2012Dec 20141.8.013.04 Raring - 13.10 Saucy
Oct 201212.10 Quantal1.7.10.42.7.3 3.2.36.0
Mar 20136.213.10 Saucy
Apr 201313.04 Raring1.8.1.22.7.4 3.3.16.1
May 2013May 2018Debian 7 Wheezy1.7.10.42.7.3 3.2.3
Sep 20136.3
Oct 201313.10 Saucy1.8.3.22.7.5 3.3.26.2
Nov 20136.4
Jan 20146.5
Feb 2014Dec 20141.9.014.04 Trusty
Mar 2014Mar 20193.4.014.04 Trusty - 15.10 Wily / Jessie
Mar 20146.614.04 Trusty - 14.10 Utopic
Apr 2014Apr 202414.04 Trusty1.9.12.7.5 3.4.06.6
May 2014Dec 20142.0.0
Aug 2014Dec 20142.1.014.10 Utopic - 15.04 Vivid / Jessie
Oct 20146.715.04 Vivid
Oct 201414.10 Utopic2.1.02.7.8 3.4.26.6
Nov 2014Sep 20152.2.0
Feb 2015Sep 20152.3.0
Mar 20156.8
Apr 2015May 20172.4.0
Apr 2015Jun 2020Debian 8 Jessie2.1.42.7.9 3.4.2
Apr 201515.04 Vivid2.1.42.7.9 3.4.36.7
Jul 2015May 20172.5.015.10 Wily
Jul 20156.915.10 Wily
Aug 20157.0
Aug 20157.1
Sep 2015May 20172.6.0
Sep 2015Sep 20203.5.016.04 Xenial - 17.04 Zesty / Stretch
Oct 201515.10 Wily2.5.02.7.9 3.4.36.9
Jan 2016Jul 20172.7.016.04 Xenial
Feb 20167.216.04 Xenial
Mar 2016Jul 20172.8.0
Apr 2016Apr 202616.04 Xenial2.7.42.7.11 3.5.17.2
Jun 2016Jul 20172.9.016.10 Yakkety
Jul 20167.316.10 Yakkety
Sep 2016Sep 20172.10.0
Oct 201616.10 Yakkety2.9.32.7.11 3.5.17.3
Nov 2016Sep 20172.11.017.04 Zesty / Stretch
Dec 2016Dec 20213.6.017.10 Artful - 18.04 Bionic - 18.10 Cosmic
Dec 20167.417.04 Zesty / Debian 9 Stretch
Feb 2017Sep 20172.12.0
Mar 20177.517.10 Artful
Apr 201717.04 Zesty2.11.02.7.13 3.5.37.4
May 2017May 20182.13.0
Jun 2017Jun 2022Debian 9 Stretch2.11.02.7.13 3.5.37.4
Aug 2017Dec 20192.14.017.10 Artful
Oct 2017Dec 20192.15.0
Oct 20177.618.04 Bionic
Oct 201717.10 Artful2.14.12.7.14 3.6.37.5
Jan 2018Dec 20192.16.0
Apr 2018Mar 20212.17.018.04 Bionic
Apr 20187.718.10 Cosmic
Apr 2018Apr 202818.04 Bionic2.17.02.7.15 3.6.57.6
Jun 2018Mar 20212.18.0
Jun 2018Jun 20233.7.019.04 Disco - Buster
Aug 20187.8
Sep 2018Mar 20212.19.018.10 Cosmic
Oct 20187.919.04 Disco / Buster
Oct 201818.10 Cosmic2.19.12.7.15 3.6.67.7
Dec 2018Mar 20212.20.019.04 Disco - 19.10 Eoan / Buster
Feb 2019Mar 20212.21.0
Apr 20198.019.10 Eoan
Apr 201919.04 Disco2.20.12.7.16 3.7.37.9
Jun 20192.22.0
Jul 2019Jul 2024Debian 10 Buster2.20.12.7.16 3.7.37.9
Aug 2019Mar 20212.23.0
Oct 2019Oct 20243.8.020.04 Focal - 20.10 Groovy
Oct 20198.1
Oct 201919.10 Eoan2.20.12.7.17 3.7.58.0
Nov 2019Mar 20212.24.0
Jan 2020Mar 20212.25.020.04 Focal
Feb 20208.220.04 Focal
Mar 2020Mar 20212.26.0
Apr 2020Apr 203020.04 Focal2.25.12.7.17 3.8.28.2
May 2020Mar 20212.27.020.10 Groovy
May 20208.3
Jul 2020Mar 20212.28.0
Sep 20208.421.04 Hirsute / Bullseye
Oct 2020Mar 20212.29.0
Oct 202020.10 Groovy2.27.02.7.18 3.8.68.3
Oct 2020Oct 20253.9.021.04 Hirsute / Bullseye
Dec 2020Mar 20212.30.021.04 Hirsute / Bullseye
Mar 20212.31.08.5
Apr 20218.6
Apr 2021Jan 202221.04 Hirsute2.30.22.7.18 3.9.48.4
Jun 20212.32.0
Aug 20212.33.08.7
Aug 2021Aug 2026Debian 11 Bullseye2.30.22.7.18 3.9.28.4
Sep 20218.8
Oct 20212.34.03.10.022.04 Jammy
Jan 20222.35.0
Feb 20228.922.04 Jammy
Apr 20222.36.09.0
Apr 2022Apr 203222.04 Jammy2.34.12.7.18 3.10.68.9
Jun 20222.37.0
Oct 20222.38.09.1
Oct 20223.11.0Bookworm
Dec 20222.39.0Bookworm
Feb 20239.2Bookworm
Mar 20232.40.09.3
Jun 20232.41.0
Jun 2023Jun 2028Debian 12 Bookworm2.39.23.11.29.2
Aug 20232.42.09.4
Oct 20233.12.09.5
Nov 20222.43.0
Dec 20239.6
Feb 20242.44.0
Mar 20249.7
Oct 20243.13.0
DateEOLGitPythonSSHUbuntu / DebianGitPythonSSH