accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] EOL 1.5
Date Thu, 21 May 2015 20:48:15 GMT
@busbey, just a slight clarification to the plan you describe in the
thread on the user@ list:

Since we'd actually be releasing the latest from 1.5 development
branch, there won't be any extra dangling unreleased commits to tag
like we did for "1.4-development-closed", so there won't be anything
to archive. It will be fully "archived" in the 1.5.3 tag, and thus not
exactly the same as what we did for 1.4.

I offer this clarification here, rather than on the user@ list,
because it's entirely a technicality which doesn't change the spirit
of what you said. I just wanted to make sure we were on the same page.
Please let me know if we're not.

Christopher L Tubbs II

On Thu, May 21, 2015 at 3:53 PM, Keith Turner <> wrote:
> +1 for 1.5 EOL
> On Tue, May 12, 2015 at 2:18 PM, Christopher <> 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

View raw message