As long as all of us agree, and try to use the same system, I think we'll be fine.
I think there's a reasonable consensus on the following understanding of "fixVersion/s", and "Affected Versions" - fixVersion: All branches that the code was committed. Example, assuming that the last released version was x.y.z: - If the code was committed to master: master (x + 1.0) - If the code was committed to the current stable branch (branch_ax), x.y + 1 - If the code was committed to a release branch - the next release version from that branch. There would be one entry for each of the release branches that this fix is committed to. - Affected Versions: All affected git tags (released versions of Lucene/Solr). If there are no objections by tomorrow morning (24 hours), I'll change the wiki page to reflect this, and it would be great if we could all just follow this convention. -Anshum > On Jul 6, 2017, at 2:40 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: > >> But for new features, it is different. The CHANGES entry is only added to >> the first version the feature was introduced (e.g. 7.0.0), even if the >> feature is committed to master, branch_7x, branch_7_0. In my head it would >> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0. > > I don't think it's that much different, really. > > If you introduce a feature on branch_7x and apply it to master then > it's both on branch_7x and master. Let's say somebody then cuts out > branch_8x from master and creates a release of version 8.0. Then that > somebody should tag patches on current master with branch_8x and 8.0 > (assuming he's immediately going for the release). And then you'd see > this on your feature issue's fix-for: > > branch_7x, branch_8x, 8.0, master > > and since branch_7x hasn't been released yet, the feature would be > introduced in version 8.0, not any tagged version on 7x (because they > haven't been released yet). You could either rollback that feature > from branch_7x (and remove the tag), or keep it and release that > feature from both branches (next version of 7x). Or never release > branch_7x at all, but keep the patch there anyway. > > Sure, this is a bit abnormal to have the same new "feature" on two > different branches, but you can apply the same thinking to bugfix > versions as well (features or any kind of patch). This is something > Hoss mentioned -- when you're doing multiple parallel releases of > versions from different branches it becomes a headache quickly to > figure out which version carries a certain patch (whether it's a bug, > feature or whatever else). But in reality it is often the case (in my > personal experience) that multiple versions do carry the same set of > patches, be it bug fixes, refactorings or even new features and those > tags in jira help to figure out where a given patch exists. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
