Project

General

Profile

Actions

Story #18249

closed

Rename release branches to X.Y-release

Added by Peter Amstutz over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Story points:
-

Description

User had trouble because they cloned from github and got the development branch. Did not understand that 2.2-dev is actually a release branch.

Suggested change:

  • X.Y-dev should be called X.Y-release
  • make latest stable branch (e.g. "2.3-release") the default branch for github (add to release checklist)

Need to rename branches & adjust references from X.Y-dev to X.Y-release.

Actions #1

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2021-10-13 sprint to 2021-10-27 sprint
Actions #2

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #3

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #4

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #5

Updated by Peter Amstutz over 1 year ago

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.
Actions #6

Updated by Tom Clegg over 1 year ago

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.

More ideas:
  • 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
Actions #7

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #8

Updated by Peter Amstutz over 1 year ago

  • Description updated (diff)
Actions #9

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2021-10-27 sprint to 2021-11-10 sprint
Actions #10

Updated by Peter Amstutz over 1 year ago

  • Target version changed from 2021-11-10 sprint to 2021-11-24 sprint
Actions #11

Updated by Peter Amstutz about 1 year ago

  • Target version changed from 2021-11-24 sprint to 2021-12-08 sprint
Actions #12

Updated by Peter Amstutz about 1 year ago

  • Description updated (diff)
Actions #13

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Peter Amstutz
Actions #14

Updated by Peter Amstutz about 1 year ago

  • Target version changed from 2021-12-08 sprint to 2022-01-05 sprint
Actions #15

Updated by Peter Amstutz about 1 year ago

  • Assigned To changed from Peter Amstutz to Ward Vandewege
Actions #16

Updated by Peter Amstutz about 1 year ago

  • Target version changed from 2022-01-05 sprint to 2022-01-19 sprint
  • Assigned To deleted (Ward Vandewege)
Actions #17

Updated by Peter Amstutz about 1 year ago

  • Subject changed from Development process feedback to Rename release branches to X.Y-release
Actions #18

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Ward Vandewege
Actions #19

Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)
Actions #20

Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)
Actions #21

Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)
Actions #22

Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)

Existing `-dev` branches:

branch
1.2-dev arvados
1.3-dev arvados
1.4-dev arvados arvados-workbench2
2.0-dev arvados arvados-workbench2
2.1-dev arvados arvados-workbench2
2.2-dev arvados arvados-workbench2 arvados-formula there are some deployments out there that used 2.2-dev, do not remove that branch
2.3-dev arvados arvados-workbench2 arvados-formula

We only have the last four pushed to github at the moment.

Things to update:
  • DONE https://dev.arvados.org/projects/arvados/wiki/Release_Checklist (though, this is now handled by art)
  • DONE rename git.arvados.org branches
  • DONE rename github branches
  • DONE /usr/local/bin/update-doc.arvados.org.sh on `public`
  • DONE arvados git repo `pre-receive` and `post-update` hooks
  • DONE local checkouts for everyone -> notify team
  • DONE doc: `_includes/_branchname.liquid` and `install/arvbox.html.textile.liquid`, also in the old release branches (2.2 and 2.3 only)
  • DONE rename git.arvados.org branches for the arvados-workbench2 repo
  • DONE rename github branches for the arvados-workbench2 repo
  • DONE arvados-workbench2 git repo `pre-receive` hooks
  • DONE rename git.arvados.org branches for the arvados-formula repo
  • DONE rename github branches for the arvados-formula repo
  • DONE arvados-formula git repo `pre-receive` hooks
Actions #23

Updated by Ward Vandewege about 1 year ago

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).

Actions #24

Updated by Ward Vandewege about 1 year ago

  • % Done changed from 0 to 100
  • Status changed from New to Resolved
Actions

Also available in: Atom PDF