Project

General

Profile

Tagging » History » Version 23

Herbert Greenlee, 06/08/2018 12:55 PM

1 5 Herbert Greenlee
{{toc}}
2 2 Herbert Greenlee
3 14 Herbert Greenlee
h1. Preparing a release from the develop branch (git flow release method)
4 1 Herbert Greenlee
5 15 Herbert Greenlee
Make an mrb development area corresponding to the base release of larsoft you are using.
6 11 Herbert Greenlee
<pre>
7 11 Herbert Greenlee
export MRB_PROJECT=larsoft
8 11 Herbert Greenlee
mrb newDev -v v04_03_01 -q e7:prof ...
9 11 Herbert Greenlee
cd $MRB_TOP
10 11 Herbert Greenlee
source localProducts*/setup
11 11 Herbert Greenlee
</pre>
12 1 Herbert Greenlee
13 11 Herbert Greenlee
If necessary, check out uboonecode and dependent packages that are not part of larsoft (ubutil).
14 1 Herbert Greenlee
<pre>
15 11 Herbert Greenlee
cd $MRB_SOURCE
16 11 Herbert Greenlee
mrb g uboonecode
17 11 Herbert Greenlee
mrb g ubutil
18 21 Herbert Greenlee
mrb g uboonedata
19 11 Herbert Greenlee
</pre>
20 11 Herbert Greenlee
21 11 Herbert Greenlee
Make sure your local copies of develop and master branches up to date with the main repository.  Do this for each checked out package.
22 11 Herbert Greenlee
<pre>
23 2 Herbert Greenlee
cd $MRB_SOURCE/<package>
24 2 Herbert Greenlee
git checkout develop
25 2 Herbert Greenlee
git pull
26 1 Herbert Greenlee
git checkout master
27 1 Herbert Greenlee
git pull
28 2 Herbert Greenlee
</pre>
29 1 Herbert Greenlee
30 11 Herbert Greenlee
Use git flow to create a release branch in your local repository.  Git flow always creates the release branch from the head of develop.  
31 10 Herbert Greenlee
<pre>
32 15 Herbert Greenlee
git flow release start <version>
33 4 Herbert Greenlee
</pre>
34 4 Herbert Greenlee
35 16 Herbert Greenlee
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.
36 2 Herbert Greenlee
37 2 Herbert Greenlee
* ups/product_deps
38 1 Herbert Greenlee
39 1 Herbert Greenlee
After making all updates, it is a good idea to do a full test build, including tests.
40 2 Herbert Greenlee
<pre>
41 1 Herbert Greenlee
cd $MRB_BUILDDIR
42 21 Herbert Greenlee
mrbsetenv
43 1 Herbert Greenlee
mrb i -j4
44 1 Herbert Greenlee
mrb t -j4
45 21 Herbert Greenlee
</pre>
46 22 Herbert Greenlee
47 11 Herbert Greenlee
When you are done updating the release branch, commit updates to your local repository for each package.
48 1 Herbert Greenlee
<pre>
49 1 Herbert Greenlee
cd $MRB_SOURCE/<package>
50 11 Herbert Greenlee
git commit -a
51 1 Herbert Greenlee
</pre>
52 1 Herbert Greenlee
53 11 Herbert Greenlee
Use git flow to "finish" the release branch.
54 11 Herbert Greenlee
55 1 Herbert Greenlee
<pre>
56 14 Herbert Greenlee
git flow release finish
57 1 Herbert Greenlee
</pre>
58 13 Herbert Greenlee
This git flow command does the following actions.
59 1 Herbert Greenlee
60 11 Herbert Greenlee
* Merges release branch to master.
61 11 Herbert Greenlee
* Merges release branch to develop.
62 11 Herbert Greenlee
* Creates a tag on the master branch.
63 11 Herbert Greenlee
* Deletes the release branch.
64 11 Herbert Greenlee
* Checks out the develop branch.
65 11 Herbert Greenlee
66 12 Herbert Greenlee
Note that when you merge the release branch into master, you are also merging any updates originally from develop into master.
67 12 Herbert Greenlee
68 11 Herbert Greenlee
Now push everything up to main repository.
69 1 Herbert Greenlee
<pre>
70 1 Herbert Greenlee
git push origin develop master
71 15 Herbert Greenlee
git push --tags
72 1 Herbert Greenlee
</pre>
73 1 Herbert Greenlee
74 1 Herbert Greenlee
h1. Preparing a hotfix release (git flow hotfix method)
75 1 Herbert Greenlee
76 18 Herbert Greenlee
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.
77 15 Herbert Greenlee
<pre>
78 20 Herbert Greenlee
git flow hotfix start <new version>
79 18 Herbert Greenlee
</pre>
80 19 Herbert Greenlee
81 18 Herbert Greenlee
If you want to patch an older tag, you must first create a new branch off of that tag.
82 18 Herbert Greenlee
<pre>
83 20 Herbert Greenlee
git checkout -b <bug_fix_branch> <old version>
84 20 Herbert Greenlee
git flow hotfix start <new version> <bug_fix_branch>
85 1 Herbert Greenlee
</pre>
86 1 Herbert Greenlee
87 20 Herbert Greenlee
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.
88 16 Herbert Greenlee
<pre>
89 16 Herbert Greenlee
git flow hotfix finish
90 1 Herbert Greenlee
</pre>
91 1 Herbert Greenlee
92 19 Herbert Greenlee
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.
93 16 Herbert Greenlee
<pre>
94 19 Herbert Greenlee
git push origin develop [master|<bug_fix_branch>]
95 16 Herbert Greenlee
git push --tags
96 16 Herbert Greenlee
</pre>
97 16 Herbert Greenlee
98 20 Herbert Greenlee
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).
99 1 Herbert Greenlee
100 11 Herbert Greenlee
h1. Tagging a branch for release (manual method)
101 1 Herbert Greenlee
102 11 Herbert Greenlee
Releases are built from the @master@ branch.  This recipe shows how to create a tag on the @master@ branch of a git repository.
103 11 Herbert Greenlee
104 11 Herbert Greenlee
Make a new mrb development area corresponding to the base release of larsoft you are using.
105 5 Herbert Greenlee
<pre>
106 11 Herbert Greenlee
export MRB_PROJECT=larsoft
107 11 Herbert Greenlee
mrb newDev -v v04_03_01 -q e7:prof ...
108 11 Herbert Greenlee
cd $MRB_TOP
109 11 Herbert Greenlee
source localProducts*/setup
110 11 Herbert Greenlee
</pre>
111 11 Herbert Greenlee
112 11 Herbert Greenlee
If necessary, check out uboonecode and dependent packages that are not part of larsoft (ubutil).
113 11 Herbert Greenlee
<pre>
114 11 Herbert Greenlee
cd $MRB_SOURCE
115 11 Herbert Greenlee
mrb g uboonecode
116 1 Herbert Greenlee
mrb g ubutil
117 21 Herbert Greenlee
mrb g uboonedata
118 11 Herbert Greenlee
</pre>
119 11 Herbert Greenlee
120 11 Herbert Greenlee
Get your local copies of develop and master branches up to date with the main repository.
121 11 Herbert Greenlee
<pre>
122 5 Herbert Greenlee
cd $MRB_SOURCE/<package>
123 1 Herbert Greenlee
git checkout develop
124 1 Herbert Greenlee
git pull
125 1 Herbert Greenlee
git checkout master
126 1 Herbert Greenlee
git pull
127 1 Herbert Greenlee
</pre>
128 1 Herbert Greenlee
129 17 Herbert Greenlee
If desired, update the master branch with changes from develop.
130 5 Herbert Greenlee
<pre>
131 11 Herbert Greenlee
git merge develop
132 5 Herbert Greenlee
</pre>
133 5 Herbert Greenlee
134 11 Herbert Greenlee
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.
135 5 Herbert Greenlee
136 5 Herbert Greenlee
* ups/product_deps
137 5 Herbert Greenlee
138 5 Herbert Greenlee
After making all updates, it is a good idea to do a full test build, including tests.
139 5 Herbert Greenlee
<pre>
140 1 Herbert Greenlee
cd $MRB_BUILDDIR
141 21 Herbert Greenlee
mrbsetenv
142 1 Herbert Greenlee
mrb i -j4
143 1 Herbert Greenlee
mrb t -j4
144 21 Herbert Greenlee
</pre>
145 22 Herbert Greenlee
146 21 Herbert Greenlee
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@.
147 21 Herbert Greenlee
148 11 Herbert Greenlee
When you are done updating master, commit and push your changes to the main repository.
149 6 Herbert Greenlee
<pre>
150 5 Herbert Greenlee
cd $MRB_SOURCE/<package>
151 11 Herbert Greenlee
git commit -a
152 11 Herbert Greenlee
git push origin master
153 1 Herbert Greenlee
</pre>
154 6 Herbert Greenlee
155 11 Herbert Greenlee
Now make the actual tag and push the tag to the main repository.
156 5 Herbert Greenlee
<pre>
157 11 Herbert Greenlee
git tag -a -m"v04_03_01" v04_03_01   # Annotated tag.
158 11 Herbert Greenlee
git push origin v04_03_01            # Or git push --tags
159 6 Herbert Greenlee
</pre>
160 11 Herbert Greenlee
If you want to move an existing tag, you need to add option @-f@ or @--force@ to the last two commands.
161 1 Herbert Greenlee
162 11 Herbert Greenlee
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.
163 1 Herbert Greenlee
<pre>
164 11 Herbert Greenlee
git checkout develop
165 11 Herbert Greenlee
git merge master
166 11 Herbert Greenlee
git push origin develop
167 1 Herbert Greenlee
</pre>