But who will remember a few months after a release, that it was 3.3.1 that went out together with 3.2.7, and not 3.3.0? When I see 3.2.7 in the fix version, I know it must be somewhere in the 3.3 line, too, but I wouldn't know that it was 3.3.1 for example. That's why I always prefer to specify both / all versions.
Cheers, Daniel On Fri, Sep 8, 2017 at 6:18 AM, Stephen Mallette <[email protected]> wrote: > a while back we'd decided that since all fixes roll forward to other > releases, that we would only add the fix version to the lowest common > release. so if you fix something 3.2.7 then it will automatically be > included in 3.3.1 (we've not had a case yet where something is only fixed > in 3.2.x but not in 3.3.x) so we just say it's fixed in 3.2.7. From a > reporting perspective this approach of adding just one fix version works > nicely because when we release we can just filter JIRA on the specific > version we are releasing without any additional filtering (which is how we > add those tickets to the changelog on release). > > On Fri, Sep 8, 2017 at 9:12 AM, Daniel Kuppitz <[email protected]> wrote: > > > > > > > a. reserve "fix version" for when we actually close the ticket > > > > > > That's how I always used to do it. However, sometimes (just recently) I > > noticed that you took away one version. The fix went into tp32/ and then > > got merged into master/. So it will end up being part of 3.2.7 and 3.3.1 > > and that's what I was using for the Fix Version. But if I remember > > correctly, you removed 3.3.1 from the Fix Version afterwards. Why's that? > > > > Cheers, > > Daniel > > > > > > On Fri, Sep 8, 2017 at 5:32 AM, Stephen Mallette <[email protected]> > > wrote: > > > > > Two quick ideas I'd like everyone to consider with respect to JIRA: > > > > > > 1. Add "component" types for each GLV rather than just the generic > > > "language variant" one we have now > > > 2. Remove the "fix version" currently assigned to all open issues > > > a. reserve "fix version" for when we actually close the ticket > > > b. this will prevent the mass of emails that come out every time we > > > release and have to move forward all the "fix version" of issues that > > > didn't close > > > c. i sense many of the items marked for completion in certain > versions > > > are no longer relevant - we've been bumping some issues forward on the > > > 3.2.x line since 3.2.1 > > > > > > Anyway, if there are no objections in the next 72 hours, I'll assume > lazy > > > consensus and move forward with these changes. Thanks! > > > > > >
