Makes sense, as long as we don’t treat it as ‘optional’ in the literal sense. We should try and put in some affected version there for the bug fixes as this entry certainly doesn’t make sense for anything other than the bugs.
-Anshum > On Jul 10, 2017, at 12:48 PM, David Smiley <david.w.smi...@gmail.com> wrote: > > RE Affected Versions. "All ..." seems wrong. to clarify, this is an optional > entry and shouldn't imply an exhaustive list. The submitter and anyone > helping can put the known version (bug experienced in version X for sure) > and/or perhaps the earliest known/believed. > > On Mon, Jul 10, 2017 at 1:58 PM Anshum Gupta <ansh...@apple.com > <mailto:ansh...@apple.com>> wrote: > 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 >> <mailto: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 >> <mailto:dev-unsubscr...@lucene.apache.org> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> <mailto:dev-h...@lucene.apache.org> >> > > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley > <http://linkedin.com/in/davidwsmiley> | Book: > http://www.solrenterprisesearchserver.com > <http://www.solrenterprisesearchserver.com/>
