Hi,
To me it is quite clear that once we released 6.0, there is technically no possibility to release a brand new 5.6 Feature-Release! The main reason: 6.0 (if released before 5.6) will not be able to read indexes of 5.6 (because it does not know about the format at the time of its release). So the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs are not allowed. And for that we already have a branch! Go ahead and commit bugfixes there! This may not fully apply to Solr on its own, but for the Lucene part this is a hard restriction (because we write version numbers into the index and compare them – so 5.6 would then break 6.0 and may lead to fatal index corrumption). So let us simply focus on getting 6.0 out – currently there was nothing significant backported to 5.x branch that would rectify a release. And bugfixes can still go into 5.5 branch, we may also commit a performance optimization into 5.5, unless it changes index formats. Personally, I will -1 every release that happens after 5.5 that changes index formats. This is just too risky! BTW. Following Mike’s release notes I posted the same thing on German Jaxenter Newsletter: https://jaxenter.de/apache-lucene-und-solr-5-5-veroeffentlicht-35271 (the smaller title over the main title reads “Last feature release before version 6”). I assume it will be translated and be released on English Jaxenter, too. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: u...@thetaphi.de From: Anshum Gupta [mailto:ans...@anshumgupta.net] Sent: Tuesday, February 23, 2016 5:53 PM To: dev@lucene.apache.org Subject: Re: Removing branch_5x shortly Sure, as I said, I agree I should have read and edited the notes. But in any case, I just thought I had missed something here. I completely understand that the job of the release manager is lonely but it was better that I got clarity on this rather than assuming things. I really appreciate you taking time and effort to manage the releases. On Tue, Feb 23, 2016 at 8:37 AM, Michael McCandless <luc...@mikemccandless.com <mailto:luc...@mikemccandless.com> > wrote: Anshum, if you don't like the wording of the release notes, please please please go and read them on the wiki and edit ahead of time, before the release is announced. It's a lonely job for the RM (alone) to go and word this, especially when they (me) are not familiar with all of the changes. In the future when the RM says "I created the Release Notes placeholders on the wiki, please edit them", which I did ~ 2 weeks ago, please do! Second, consensus here was to not remove the git branch since 1) this is apparently technically a disaster with git, requiring all users who had cloned to run a cryptic command, and 2) it would "preclude" a future 5.6.0 (though, that's not really true). It seems to me we should never remove any pushed git branches. Third, there is no reason/need to talk about consensus about a hypothetical future 5.6.0 release: that depends entirely on how the future unfolds, as Jack and Yonik explain. In general, in your life, there is no need (and indeed only added risk) to make a decision today that can safely be postponed. Let the future unfold first so you have all data, and only make the (better informed) decision once you must. Fourth, by releasing 6.0, shortly, we (Lucene/Solr devs) are declaring to our users that we intend future new features to go into 6.1, 6.2, etc., the new stable branch. I don't think we want / can afford to have two stable branches at once. Mike McCandless http://blog.mikemccandless.com On Tue, Feb 23, 2016 at 10:55 AM, Jack Krupansky <jack.krupan...@gmail.com <mailto:jack.krupan...@gmail.com> > wrote: > 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 > <mailto: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 >> <mailto: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 >>> <mailto: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 <mailto: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 >>>>> <mailto:dev-unsubscr...@lucene.apache.org> >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> <mailto:dev-h...@lucene.apache.org> >>>>> >>>> >>>> -- >>>> Uwe Schindler >>>> H.-H.-Meier-Allee 63, 28213 Bremen >>>> http://www.thetaphi.de >> >> >> >> >> -- >> Anshum Gupta > > --------------------------------------------------------------------- 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> -- Anshum Gupta
