We could do a poll.
In the end it will probably happen organically - like it did with 0.94.
It's not a decision to be made per se - it's open source after all.As long as
patches are backported and issues are reported against 0.98 there is a need
and, IMHO, we should continue doing releases. If/When that stops users and
contributors have lost interest and we can EOL.
With that, looking at 0.98.21 with 44 resolved/closed issues, 22
open/in-progress/patch-available, that looks pretty healthy and in demand to
me!(Unless it's all your doing, Andy... Also looks like it's time for an
0.98.21 RC :) )
Of course then there's the question of how much work we - as volunteers - are
willing to put into this.
I like the general statement about maintenance, stable, and unstable.
Perhaps that needs to be played by ear to some extent? What if - as an example
- we had called the next release not 1.3 but 2.0 and introduced major breaking
changes (as much as we allow ourselves per the compatibility guide)? Would we
maintain 1.1.x, 1.2.x *and* 2.0.x and 2.1.x, because folks might be stuck a bit
longer with 1.x?
-- Lars
From: Andrew Purtell <[email protected]>
To: [email protected]
Sent: Monday, July 25, 2016 12:07 PM
Subject: Re: Feedback from the July 2016 board report
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)
>>
