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! >> > > > >> > > >> > >> > >
