I agree. No one says anything about deliberately introducing new features in a 5.6. At least from my POV, I'd like to be able to not take down my Solr cluster when upgrading to 6.0, so if any work needs to happen on the 5x branch (and maybe also on the 6x branch) to make that happen, I'll gladly do it. Even if it means that eventually I will only be able to upgrade from 5.5 to 6.1 and have to skip all other releases.
I'm pretty sure that's the spirit of changes that will go into future 5x releases (and I don't think it's gonna be a loong future after 6.0 is out) -- definitely not index format changes. Shai On Tue, Feb 23, 2016 at 8:28 PM Mark Miller <[email protected]> wrote: > It's just an example though. Beyond simple features and improvements, > there are also lots of things we do under Other and Optimizations that we > would not not necessarily consider for a bug fix release (higher bar), but > that would be in a 5.6 release. A jetty point release update for example. > > - Mark > > On Tue, Feb 23, 2016 at 1:10 PM Nicholas Knize <[email protected]> wrote: > >> > Things that help users migrate from 5x to 6x that we perhaps missed out. >> >> This may be semantics but these sound to me like bugs? Not features? >> >> >> On Tuesday, February 23, 2016, Anshum Gupta <[email protected]> >> wrote: >> >>> My thoughts exactly. >>> >>> The features that go into a possible 5.6 or 5.7 release would be stuff >>> that is unrelated to index format. Things that help users migrate from 5x >>> to 6x that we perhaps missed out. I'm just saying there's a real valid >>> possibility of such a release. >>> >>> >>> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller <[email protected]> >>> wrote: >>> >>>> I just want to point out: just like the previous line of bug fix >>>> releases dies down heavily, so would the feature backports. They will >>>> likely be simple useful things rather than crazy complicated hard things. >>>> There probably won't be that many, just like the bug fix releases. Let's >>>> not pretend it's going to end up like an active branch with devs always >>>> wondering if the new codec they are slamming in is going to mess things up. >>>> >>>> If there is any demand for this, it's going to be by people on 5x for >>>> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may >>>> or may not be any better. Upgrading a major release can be quite disturbing >>>> and many users take a long, long time to do it. >>>> >>>> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than >>>> our two main branches. Users can simply gobble them up, rather than choke >>>> them down like a major release. Useful features can be found that may not >>>> affect index format. >>>> >>>> Anyway, if there ends up being demand, I'll certainly be one of the >>>> 3 +1's needed. >>>> >>>> - Mark >>>> >>>> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <[email protected]> >>>> wrote: >>>> >>>>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <[email protected]> >>>>> wrote: >>>>> >>>>>> 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! >>>>>> >>>>> That makes no sense. There are only a handful of people committing >>>>> index format changes. It's beyond simple for those people to understand >>>>> once the next major version is released, don't put any more index format >>>>> changes into the previous line. >>>>> >>>>> That is a very weak technical argument. Committers already have to >>>>> remember how to deal with back compat and what changes can happen when. >>>>> This is no different. >>>>> >>>>> - Mark >>>>> -- >>>>> - Mark >>>>> about.me/markrmiller >>>>> >>>> -- >>>> - Mark >>>> about.me/markrmiller >>>> >>> >>> >>> >>> -- >>> Anshum Gupta >>> >> -- > - Mark > about.me/markrmiller >
