Project

General

Profile

Preparing a release from the develop branch (git flow release method)

Make an mrb development area corresponding to the base release of larsoft you are using.

export MRB_PROJECT=larsoft
mrb newDev -v v04_03_01 -q e7:prof ...
cd $MRB_TOP
source localProducts*/setup

If necessary, check out uboonecode and dependent packages that are not part of larsoft (ubutil).

cd $MRB_SOURCE
mrb g uboonecode
mrb g ubutil
mrb g uboonedata

Make sure your local copies of develop and master branches up to date with the main repository. Do this for each checked out package.

cd $MRB_SOURCE/<package>
git checkout develop
git pull
git checkout master
git pull

Use git flow to create a release branch in your local repository. Git flow always creates the release branch from the head of develop.

git flow release start <version>

This command creates a new branch off of the head of develop called release/<version>. After this command, the newly created release branch will be the checked out branch. At this point, you can make further changes to your release branch, including the version number of the package being tagged and version numbers of dependent products. In particular, you may with to edit the following files.

  • ups/product_deps

After making all updates, it is a good idea to do a full test build, including tests.

cd $MRB_BUILDDIR
mrbsetenv
mrb i -j4
mrb t -j4

When you are done updating the release branch, commit updates to your local repository for each package.

cd $MRB_SOURCE/<package>
git commit -a

Use git flow to "finish" the release branch.

git flow release finish

This git flow command does the following actions.
  • Merges release branch to master.
  • Merges release branch to develop.
  • Creates a tag on the master branch.
  • Deletes the release branch.
  • Checks out the develop branch.

Note that when you merge the release branch into master, you are also merging any updates originally from develop into master.

Now push everything up to main repository.

git push origin develop master
git push --tags

Preparing a hotfix release (git flow hotfix method)

Prepare your development area as in the previous section, up to the "git flow release start" command. If you are patching a release that corresponds to the current head of the master branch (i.e. the most recent tag), start your hotfix branch using the following command.

git flow hotfix start <new version>

If you want to patch an older tag, you must first create a new branch off of that tag.

git checkout -b <bug_fix_branch> <old version>
git flow hotfix start <new version> <bug_fix_branch>

Either command creates a new branch called hotfix/<new version>. Make updates and test your hotfix branch as in the previous section. When you are done, use the following command to finish the hotfix.

git flow hotfix finish

This command merges the hotfix branch to master (or bug fix) and develop branches, and creates a new tag on the master or bug fix branch. Then push your updates up to the main repository.

git push origin develop [master|<bug_fix_branch>]
git push --tags

The main difference between "git flow release" and "git flow hotfix" is that the former works off of develop, and the latter works off of master (or bug fix branch).

Tagging a branch for release (manual method)

Releases are built from the master branch. This recipe shows how to create a tag on the master branch of a git repository.

Make a new mrb development area corresponding to the base release of larsoft you are using.

export MRB_PROJECT=larsoft
mrb newDev -v v04_03_01 -q e7:prof ...
cd $MRB_TOP
source localProducts*/setup

If necessary, check out uboonecode and dependent packages that are not part of larsoft (ubutil).

cd $MRB_SOURCE
mrb g uboonecode
mrb g ubutil
mrb g uboonedata

Get your local copies of develop and master branches up to date with the main repository.

cd $MRB_SOURCE/<package>
git checkout develop
git pull
git checkout master
git pull

If desired, update the master branch with changes from develop.

git merge develop

At this point, you can make further changes to your master branch, including the version number of the package being tagged and version numbers of dependent products. In particular, you may with to edit the following files.

  • ups/product_deps

After making all updates, it is a good idea to do a full test build, including tests.

cd $MRB_BUILDDIR
mrbsetenv
mrb i -j4
mrb t -j4

Note that if you have uboonedata checked out, it may be necessary to remove uboonedata from the master CMakeLists.txt and reinitializing the build environment using mrbsetenv before running mrb t.

When you are done updating master, commit and push your changes to the main repository.

cd $MRB_SOURCE/<package>
git commit -a
git push origin master

Now make the actual tag and push the tag to the main repository.

git tag -a -m"v04_03_01" v04_03_01   # Annotated tag.
git push origin v04_03_01            # Or git push --tags

If you want to move an existing tag, you need to add option -f or --force to the last two commands.

If you made changes directly on the master branch, like updating the version number in product_deps, you should merge these back into the develop branch.

git checkout develop
git merge master
git push origin develop