+1 to Enis' suggestions of documenting in the ref guide (and then keeping it up to date). "Which HBase version should I use?" is a frequently-enough asked question that we should answer it in a central place. https://hbase.apache.org/book.html#_get_started_with_hbase seems like a decent enough place to start?
-Dima On Mon, Jul 25, 2016 at 12:07 PM, Andrew Purtell <[email protected]> wrote: > 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) > >> >
