I’ve put this on a wiki page, and did that as a ‘trivial change’, which shouldn’t have triggered any emails to anyone other than Steve (sorry about that). I’m not sure how to have that as a permanent setting for this page though.
Anyone? Here’s the page: https://wiki.apache.org/lucene-java/SettingFixVersions -Anshum > On Jul 5, 2017, at 3:10 PM, David Smiley <david.w.smi...@gmail.com> wrote: > > This makes sense to me. It's easy to forget this stuff though. Perhaps we > can propose a policy, vote on it, and post it somewhere? We could even do > this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal" > prominently at the top, and then share a link. Keep it particularly succinct > so it's easy to see what the essence is, and then only potentially later > decorate with tips & whatever else. It'd be nice but not required to have > changes to this page (and some selected others) be auto-copied to the dev > list somehow, e.g. by having a special account, but not required. > > On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta <ansh...@apple.com > <mailto:ansh...@apple.com>> wrote: > @Dawid: I remember that discussion, and I think things were fixed for the > issue back then. > > My concern right now is that we will end up in a similar situation again with > everyone interpreting the fixVersion differently. > > @Erick > Here’s my issue with that approach. Say I commit something that would be > released with 7.0 but obviously, I also commit to master at this point. Going > with your approach here are the fix versions I’ll end up with on the JIRA - > master (8.0), 7.1, and 7.0. > > This confuses me, as anything that has a 7.0 fix version shouldn’t have > anything else from the 7x line. Also, it shouldn’t have anything from a line > greater than that i.e. master (8.0) as it is obvious to me that there can not > be any fix that makes it’s way into 7.0 but not 7.1, or 8.0. > > Also, from my understanding, a fix version of 7.1 would mean that the first > time this was released on the 7x line was 7.1 (which wouldn’t be the case > here). > > Yes, things would work differently for bug fix releases, but I’m talking > about the major release version here. > > Here’s my suggestion: > > - For a fix that will be released with a major version, just mention the > major version > - For a minor version > - master (current version + 1) > - minor version release that would have this fix > - all prior bug fix releases, when this is back-ported to older branches > - Bug fix release > - The only case when a fix is released with such a release, is when > - The issue was introduced by a minor version release right > before this release AND > - There was no other minor/major release since this issue was > introduced. > - In such a case, the fix version should only have the bug fix version, > and not master, etc. > > What would also be useful here is specifying the ‘Affects Version’ but in my > experience, this gets tough to figure at times for bug fixes, and doesn’t > generally make sense for new features/enhancements. > > If there’s anything else, I’d be happy to just go with whatever everyone > wants to follow as long as it makes things easier to understand and manage. > > > -Anshum > > > >> On Jul 5, 2017, at 2:13 PM, Erick Erickson <erickerick...@gmail.com >> <mailto:erickerick...@gmail.com>> wrote: >> >> I'm just including a fix version for each push I make. I.e. >> >> If I push to master I'll add "master (8.0)". >> If I push to 7x, at this point I'll add 7.1 >> If I push to 7_0 I'll add 7.0 >> If I push to 6x I'll add 6.7 >> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1 >> >> I think one push == one label is unambiguous. You do have to realize >> that if there may never be, say, a 6.6.1 in my example. But we do >> remove the onus of people having to figure out what a fix version of >> plain "master" or "7x" means. >> >> FWIW >> Erick >> >> >> >> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss <dawid.we...@gmail.com >> <mailto:dawid.we...@gmail.com>> wrote: >>> There's been a fairly recent discussion about it on the mailing list >>> (David Smiley and were involved in that discussion, among other >>> people). There are many different takes on how to handle fix-for and >>> branches. I don't think we can find the "best" strategy, although >>> perhaps we can agree on something project-specific. I've expressed my >>> opinion on that previous post, but I'm open to any strategy. >>> >>> Dawid >>> >>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta <ansh...@apple.com >>> <mailto:ansh...@apple.com>> wrote: >>>> Hi, >>>> >>>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that >>>> are being committed right now. I think it makes sense for the fixVersion to >>>> just be 7.0, and nothing else for everything that is going into branch_7_0, >>>> instead of being both 7.0, and master (8.0). >>>> >>>> Any thoughts? >>>> >>>> -Anshum >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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> >>> >> >> --------------------------------------------------------------------- >> 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/>
