On Thu, Jan 29, 2015 at 11:57 AM, Julian Hyde <[email protected]> wrote: > >> On Jan 29, 2015, at 11:48 AM, James Taylor <[email protected]> wrote: >> >> - always release out of a branch and never out of master > > We just started doing this in the 1.0 release. The issue I struggled with is > this: suppose that you fix a bug on the 1.0 branch before you release 1.0 but > after you have branched from master. After the release you will apply the > patch for that bug to the master branch. But since other changes have been > made to the master branch, the commit hash will be different. > > So... which commit hash do you use when you mark the bug fixed? The one on > the 1.0 branch or the one of the master branch?
The Jenkins builds add comments with the commit hash and files changed when the build is complete after the commit, so we'll end up with one comment per branch checked in. > > >> - set the Fixed Version at the time it is committed to the release(s) >> that'll contain the fix. This way we can easily run a query that shows >> all the JIRAs fixed in a given release. > > So, when you mark the bug fixed, and commit the patch to git (it might be to > master or to the branch) you don't record the fix version? If so, how do you > figure out which bugs were fixed in a release? When the bug is resolved by the person who made the fix, they set the fix version(s) too (where the fix version corresponds to the release in which the fix will appear). > > Our process is to mark the bug fixed and set its fix version when the patch > is committed to master, then mark the bug closed (with the same fix version) > when the release is made. > > Not to say that our process is better. Appreciate hearing how others do it. > Yep, lots of ways to do it. > Julian >
