+1 for labeling all versions applied to
Robert Dale On Mon, Sep 11, 2017 at 6:46 AM, Stephen Mallette <spmalle...@gmail.com> 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 <spmalle...@gmail.com> > 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 <m...@gremlin.guru> 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 <spmalle...@gmail.com> > >> 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 <m...@gremlin.guru> > 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 < > >> spmalle...@gmail.com> > >> > > 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! > >> > > > > >> > > > >> > > >> > > > > >
