I think people are missing my point. I am _not_ advocating having "two major feature branches developed at once". I'm pointing out that between now and the 7.0 release (and possibly for a bit thereafter), there will be a number of JIRAs that _could_ be backported to a (future) 6.7 with virtually no effort. Some of these will be quite helpful to clients. Trust me on this.
There's no good reason to _artificially_ refuse to backport a JIRA if it's easy just because "we're releasing 7.0". It always takes a while for the next major version to burn in so there's this gray period between when 7.0 is cut and when 7.0.x will have enough mileage on it to be the go-to version for production systems. The key here is "if it's easy". I'm _not_ advocating that every new commit to 7x has to be backported. If it doesn't backport cleanly with near-zero effort, don't bother. If you're working on a nifty new feature that would require extra work to back-port to 6x, don't bother. If you can back-port it in 5 minutes with a simple merge between now and when 7.0.x becomes our go-to, please consider it. I also suspect that many of the Lucene-level changes are far more difficult to back-port than many of the Solr changes, the Lucene code has to deal with gnarly back-compat issues a lot more. So I'd rather expect that many Lucene changes can't get back-ported because it's not easy, especially when all the deprecated code is removed, which is fine. Just let's not automatically exclude the idea of back-porting a JIRA to 6x if it can be done with minimal effort just because 7.0 is being planned. We've always had JIRAs back-ported to newest_release-1x to be picked up _if_ there's another release along that branch, so I don't understand why this is at all controversial. Best, Erick On Thu, May 25, 2017 at 7:18 AM, Michael McCandless <[email protected]> wrote: > On Thu, May 25, 2017 at 9:16 AM, David Smiley <[email protected]> > wrote: >> >> On Thu, May 25, 2017 at 9:06 AM Shawn Heisey <[email protected]> wrote: >>> >>> > To me the best trade-off is to stop doing 6.x minor releases once 7.0 >>> > is out. >>> >>> I did say it would be relatively safe to do bugfixes and backport >>> self-contained features in 6.x after 7.0 comes out as long as care is >>> taken to not change the index format or analysis component behavior. >>> >>> Despite saying that, I actually agree with you that new minor releases >>> (and therefore new features) should be avoided in the previous major >>> version unless there is a VERY compelling reason. It doesn't seem very >>> likely that a compelling reason will be encountered. >> >> >> Why? If someone (not you, obviously), is willing to be the RM, then >> what's it to you? > > > It's more than just an RM volunteer to do another 6.x feature release; it's > also our collective effort to back-port features to 6.x, to spend limited CI > resources running 6.x tests, etc. > >> I think there's nothing wrong with a 6.whatever release following a 7.0. > > > I don't think that makes much sense. > > Why would we choose to have two major feature branches developed at once? > Once 7.0 is out, we should work hard towards the next (7.1) feature release, > and leave 6.6.x open only for bug fixes. > > Mike McCandless > > http://blog.mikemccandless.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
