On a closely related topic - the retiring of 0.98 - can I ask for your opinions on timeframe to sunsetting? I am happy to continue maintaining it for as long as that would be desirable and useful. On the other hand at some point it's a legacy we need to move on from. If there's some guidance on this let's include it in what we are writing up.
> On Jul 25, 2016, at 11:21 AM, Enis Söztutar <[email protected]> wrote: > > +1 to above. > > This is what I used as a "guide to selecting a release": > http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=clipshare > > Should we document this in the book somehow? We should put extra effort to > keep it up to date. > > Enis > >> On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <[email protected]> wrote: >> >> Maybe it's worth spelling out? It will become more obvious once 0.98 is >> retired. I think of them like this: >> >> 0.98.x -- legacy >> 1.x -- current >> >> Within current, we have >> >> 1.0.x -- retired/EOL >> 1.1.x -- maintenance >> 1.2.x -- stable >> 1.3.x -- unstable >> >> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on. >> >>> On Friday, July 22, 2016, Andrew Purtell <[email protected]> wrote: >>> >>> In our last board report we mentioned the several code lines we current >>> manage and were asked to consider some form of support policy so the >>> community is able to make informed decisions about which release line to >>> use. >>> >>> The first question is: should we have one? >>> >>> The second question, if the answer to the first is 'yes', is what that >>> policy should be. >>> >>> >>> >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) >>
