Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9Yycv7Rt++uBHKJR44qkhouOnfz0dQMdQiSp7tSBJNBug@mail.gmail.com>
References: 
 <CAL5zq9Yycv7Rt++uBHKJR44qkhouOnfz0dQMdQiSp7tSBJNBug@mail.gmail.com>
From: Sean Busbey <busbey@cloudera.com>
Date: Tue, 12 May 2015 13:53:56 -0500
Message-ID: 
 <CAGHyZ6+vmep3UcgS0Q83zTZpcZ_UuNKK8yHjuHT7yMM5UR1eLw@mail.gmail.com>
Subject: Re: [DISCUSS] EOL 1.5
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b8738a27a000b0515e705e8

--047d7b8738a27a000b0515e705e8
Content-Type: text/plain; charset=UTF-8

+1 to making sure we have a 1.5.3 before stop dev

I'd like to make sure we get through some testing of 1.5 -> 1.7 upgrade
testing before declaring dev over, just to give people more assurance that
they can upgrade off of the version.

On Tue, May 12, 2015 at 1:18 PM, Christopher <ctubbsii@apache.org> wrote:

> How do we want to EOL 1.5?
>
> Personally, I was thinking (soon after 1.7.0 is released):
> * Release and tag 1.5.3
> * Remove 1.5 branch to focus active development on newer versions
> * Be willing to branch from the 1.5.3 tag to rapidly release a 1.5.4
> in response to critical bugs
>
> My biggest concerns are:
> 1) We turn exhausted people off by doing burdensome release testing,
> which delays bugfixes in 1.5, and
> 2) We get into a situation where 1.5.3 has some bugs that we never
> fix, which sends a confusing message to stick with 1.5.2.
>
> There's also the concern that there's a fair amount of work that was
> put into 1.5.3, and I'd hate to have those contributions not be
> available to users of 1.5.
>
> I figure that so long as we're willing to fix critical bugs, we can
> formally cease active development (EOL), without going so far as to
> say that 1.5 users are completely screwed if a critical bug is
> identified.
>
> What I'm describing isn't really an EOL date, so much as an EOL period
> which begins when we cease active development on 1.5, and ends
> organically at some arbitrary point in the future when people stop
> reporting critical bugs (or we reach a point where maintaining it is
> too costly... a sort of "EOL-2").
>
> Another way to look at what I'm suggesting is switch from a "sustained
> development" model to a "branch to fix and release" model, where
> patch/bugfix releases are more narrowly scoped and can occur more
> rapidly, on demand.
>
> Thoughts? Alternatives? Variations? Objections?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>


-- 
Sean

--047d7b8738a27a000b0515e705e8--