This would be good to see as part of the How To Contribute guide, I think, or at least linked from there.
On Wed, Jul 5, 2017 at 5: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> 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> >> 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> >> 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> 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 >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www. > solrenterprisesearchserver.com >
