Arvados

How about this:

1. X.Y-dev is still actually a development branch for that release.
2. When the release happens, we create a X.Y-release branch. This points to latest release in the X.Y series. The head of the branch should be the same as the tag for the latest release. This branch is only updated for actual releases.
3. On each major release, go to github and set the "default branch" to the X.Y-release branch.

It seems a bit weird to me to arrange our github setup to accommodate the (anti?)pattern of an install recipe that starts by cloning a git repo.

• at https://doc.arvados.org/v2.2/install/salt-single-host.html, provide a snippet that does the exactly correct "git clone" command (the current language is "cloning the 2.2-dev branch from {url}" which makes it easy to forget the checkout step, and depending on familiarity with git might even be misinterpreted to mean "cloning {url} gives you the 2.2-dev branch")
• in the provision.sh script, error out if being run from a git tree with a non-released version and the user isn't explicitly asking for a development version

Instructions to fix local checkouts of the old `-dev` branches (e.g. for 2.3):

git remote update origin --prune # update the list of remote branches
git branch -d 2.3-dev            # delete the local 2.3-dev branch
git checkout 2.3-release         # checkout the new 2.3-release branch

Please don't push the old `-dev` branches again (it will not be allowed, I updated our git hook to check for that).