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> 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> 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> > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Anshum Gupta
