Sure, it will all hinge on the uptake of 6.x vs. demand for features in 5.x from sites who feel that they cannot easily upgrade to 6.x. But in any case, it seems reasonable for there to be a distinct bias in favor of people migrating to 6.x for new features rather than divert attention from 6.x, and that new features should be optimized for 6.x rather than dumbed-down to remain compatible with 5.x.
Sure, practicality may well force a 5.6, but as you say, we haven't gotten to that bridge yet. I mean, is anybody proposing a list of urgent features that should go in 5.x rather than 6.x? It does seem clear that the technical possibility of a 5.6 remains even though the clear bias and expectation is that 6.x is where people should be looking for new features. Personally, I don't think we will have a clear answer until we get to 6.1 - at that point it will be reasonably clear whether demand for enhancement of 5.x is really there or not. I say all of this presuming that 6.0 is imminent within the next few weeks. It seems reasonable to have feature releases (minor releases) on a monthly basis, so if 6.0 is not out a month from now, then a 5.6 would be a very reasonable expectation. -- Jack Krupansky On Tue, Feb 23, 2016 at 10:34 AM, Anshum Gupta <ans...@anshumgupta.net> wrote: > I thought we had a consensus here in terms of being able to have another > 5x release if someone felt the need and volunteered but I guess that wasn't > the case. I say that because I just saw the following line in the release > notes for 5.5: > > "This is expected to be the last 5.x feature release before Solr 6.0.0." > > If everyone else also thinks that it would have not been reasonable to > leave a possibility of another 5x release, I'm fine. We might have to > evaluate it *if* we get to that bridge though. > > > On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <noble.p...@gmail.com> wrote: > >> Yeah, please don't remove it. Let it be there. >> On Feb 21, 2016 01:02, "Uwe Schindler" <u...@thetaphi.de> wrote: >> >>> Hi, >>> >>> Let's keep the branch. The other ones from 3 and 4 are also still there. >>> >>> If anybody commits, who cares? If we don't release, it's just useless >>> work. >>> >>> If we want to nuke branch, do the same for previous ones. >>> >>> Uwe >>> >>> Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss < >>> dawid.we...@gmail.com>: >>>> >>>> Can't we tag it and then delete the branch? >>>>> >>>> >>>> Any reference. So yes, sure you can. But this doesn't really address >>>> the second part of my e-mail -- people would still have to issue: >>>> >>>> git remote prune origin >>>> >>>> and I don't want to fight Uwe over supposedly magical git commands :) >>>> >>>> if infra let's us put in any git hooks and protect branches from there. >>>>> >>>> >>>> Yes, this would be another option (but it requires admin-side tweaks). >>>> >>>> I'm not convinced we need a new strategy just because we are on git >>>> though. >>>>> We generally don't decide >>>>> we won't do a release, someone volunteers to put >>>>> one together when something prompts it. I don't remember protecting >>>>> branches >>>>> in SVN and so I wonder if we need to now? >>>>> >>>> >>>> Exactly. We really don't need to do anything other than just agree to >>>> not commit there... that's part of the reason I wanted more "semantic" >>>> names for branches -- they're kind of hard to eradicate once created >>>> in public. >>>> >>>> Anyway, as for branch_5x -- no need to protect anything, really. If >>>> somebody DOES commit something (by accident or otherwise) we can >>>> always revert those commits (or even force the reference to what it >>>> was before the mistake, effectively undoing the change). >>>> >>>> D. >>>> >>>> ------------------------------ >>>> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >>> -- >>> Uwe Schindler >>> H.-H.-Meier-Allee 63, 28213 Bremen >>> http://www.thetaphi.de >>> >> > > > -- > Anshum Gupta >
