Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Wed, 27 Jul 2016 17:28:20 +0000 (UTC)
From: <larsh@apache.org>
Reply-To: <larsh@apache.org>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Message-ID: <191720686.5242168.1469640500580.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <207EF7A4-8C88-4A36-8DAB-D32812ABFDB2@gmail.com>
References: <CA+RK=_BdAwR+1mWGnayzBwneq8eRvVY7WLQYi03qUYsCRV_YTQ@mail.gmail.com> <CANZa=GtdzvjgUkoKKF699MsLHcW2bVTpO7MTbAMXu+vwCXLfRQ@mail.gmail.com> <CAMUu0w9axsZWuQdgZZ5=ZDYpm1tT5rw-qAUMGhZ8CAxx6ZbmUQ@mail.gmail.com> <207EF7A4-8C88-4A36-8DAB-D32812ABFDB2@gmail.com>
Subject: Re: Feedback from the July 2016 board report
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5242167_1912814053.1469640500576"
archived-at: Wed, 27 Jul 2016 17:28:35 -0000

------=_Part_5242167_1912814053.1469640500576
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 n=
eed 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-pr=
ogress/patch-available, that looks pretty healthy and in demand to me!(Unle=
ss 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 - a=
re 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 exam=
ple - we had called the next release not 1.3 but 2.0 and introduced major b=
reaking 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 <andrew.purtell@gmail.com>
 To: dev@hbase.apache.org=20
 Sent: Monday, July 25, 2016 12:07 PM
 Subject: Re: Feedback from the July 2016 board report
  =20
On a closely related topic - the retiring of 0.98 - can I ask for your opin=
ions 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 po=
int 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.=20


> On Jul 25, 2016, at 11:21 AM, Enis S=C3=B6ztutar <enis@apache.org> wrote:
>=20
> +1 to above.
>=20
> This is what I used as a "guide to selecting a release":
> http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=3Dclips=
hare
>=20
> Should we document this in the book somehow? We should put extra effort t=
o
> keep it up to date.
>=20
> Enis
>=20
>> On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote=
:
>>=20
>> Maybe it's worth spelling out? It will become more obvious once 0.98 is
>> retired. I think of them like this:
>>=20
>> 0.98.x -- legacy
>> 1.x -- current
>>=20
>> Within current, we have
>>=20
>> 1.0.x -- retired/EOL
>> 1.1.x -- maintenance
>> 1.2.x -- stable
>> 1.3.x -- unstable
>>=20
>> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so o=
n.
>>=20
>>> On Friday, July 22, 2016, Andrew Purtell <apurtell@apache.org> wrote:
>>>=20
>>> 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 t=
o
>>> use.
>>>=20
>>> The first question is: should we have one?
>>>=20
>>> The second question, if the answer to the first is 'yes', is what that
>>> policy should be.
>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Best regards,
>>>=20
>>>=C2=A0 - Andy
>>>=20
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hei=
n
>>> (via Tom White)
>>=20

  
------=_Part_5242167_1912814053.1469640500576--