Hi Glenn,

On 18/12/2012 16:27, Glenn Adams wrote:

On Mon, Dec 17, 2012 at 7:54 AM, Chris Bowditch <bowditch_ch...@hotmail.com <mailto:bowditch_ch...@hotmail.com>> 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

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.




Reply via email to