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 <nkn...@gmail.com> 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 <ans...@anshumgupta.net> > 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 <markrmil...@gmail.com> >> 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 <markrmil...@gmail.com> >>> wrote: >>> >>>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <u...@thetaphi.de> 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
