Hi Glenn,
On 18/12/2012 16:27, Glenn Adams wrote:
On Mon, Dec 17, 2012 at 7:54 AM, Chris Bowditch
<[email protected] <mailto:[email protected]>> wrote:
Hi Glenn,
On 17/12/2012 15:24, Glenn Adams wrote:
but after a new release, the issue would effectively apply to
both trunk and the new release, and an issue can only be
associated with one version in JIRA;
But why does that matter? If a bug is fixed then in v3 say, then
its obvious its also fixed in v4.
Not at all. If it is fixed in the v3 branch, e.g., in order to create
a subsequent v3.1 release from that branch, then that doesn't imply
anything about a fix in a v4 branch.
This seems like a corner case to me. A bug tracking system can't tell
you the relationship between branches, i.e.
v3 contains the fix
v3.1 was based on v2 and doesnt contain it
v4 does contain the fix because it was based on v3
v4.1 doesn't contain the fix because it was based on v3.1
etc
I don't believe we've ever done something like the above on the FOP
project. Although I admit having to deal with such scenarios on
commercial projects. We also had terrible trouble with the fixed in
version for such projects and just didn't use it, which lead to release
planning being conducted with list of defects in e-mails or spreadsheets
and not using the BTS.
Jira also has a concept of labels and an issue can have zero or many
labels, so we could decide to label issues as being in particular
releases if the PMC feels that the multiple release branch scenario is
likely. (Labels can also be reported on so we can list defects fixed in
a given release) The downside to labels is that they are freetext
instead of a dropdown and anyone can create them, which leads to a long
list of labels like v2.0, 2.0, R2.0.0, etc.
I personally don't see a problem with the proposal as FOP has always had
a linear release pattern without multiple release branches to worry
about but we can have a formal vote on this topic if needed.
if the issue isn't fixed by the time the release occurs, then
it is unlikely to be fixed in the release version as much as
being fixed in trunk; so that would argue for keeping the
issue associated with trunk and not the new version
Are you saying there is a possible flaw in the suggested process
that mean some bugs fixed after the release branch were created
are marked incorrectly. IIUC, As long as the fixed in version is
updated at the same point in time the release branch is created
this should be a non issue.
I don't understand this.
Me neither I was trying to get you to clarify your point.
Thanks,
Chris
<snip/>
