I'm +1 on adding all fix versions that it was applied to. I'm +1 on adding a component per GLV.
On Mon, Sep 11, 2017 at 1:07 PM, Robert Dale <[email protected]> wrote: > +1 for labeling all versions applied to > > > > Robert Dale > > On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <[email protected]> > wrote: > > > I thought about the "Fix version" situation - I guess I don't really care > > which way we do it so long as it is consistent. If it is more intuitive > to > > everyone to add all the versions that a fix went in on then i'm fine to > do > > that. However, I do think the CHANGELOG is cleaner to look at without all > > the duplication, so if we did go down that path the release manager would > > just need to make sure that the appropriate JIRAs were filtered out > which I > > suppose isn't too hard. Anyone prefer that we assign all the fix versions > > as necessary in JIRA? > > > > On Fri, Sep 8, 2017 at 9:40 AM, Stephen Mallette <[email protected]> > > wrote: > > > > > You would only know through tribal knowedge and the changelog I guess. > > > > > > sucks - i just realized that there are duplicates all through the > > > changelog because there's been spotty application of a single fix > > version. > > > dah > > > > > > On Fri, Sep 8, 2017 at 9:33 AM, Daniel Kuppitz <[email protected]> > wrote: > > > > > >> 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! > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
