accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 19:48:43 GMT

On Mon, May 12, 2014 at 12:00 PM, Sean Busbey <> wrote:
> Overall, I like this plan. Ideally, it'd be best if we could limit our
> active branches to major versions and avoid creating major version branches
> while we still are waiting on a previous major release's last minor release.
> Once we've fully transitioned to a new versioning scheme, what do we expect
> the steady state to be?
> How about something like the following:
> * We vote on a release plan that establishes a new major version
> * major version created in jira
> * wrap up last planned minor release on previous major version
>     * During this time, keep any incompatible patches meant for hte major
> version in jira
> * release last minor release of previous major version
> * create new major version branch, remove previous major version branch
> * apply patches from jira for new major version

I agree that it makes sense to vote on a release plan to establish a
new major version. I'm not sure I followed the rest, but I think once
a new major version is released, minor releases on the previous major
one should stop. But, minor releases on the last released major
version can continue until the next major version is released. That
would imply one major version (eg. 2.0.0) branch under development at
a time, and one minor (eg. 1.7.0) on top of the last major, and bugfix
branches only existing in preparation for releasing.

> This way we only have one major development branch at a time.  When there
> are new bug fixes that come in for a supported version we can create a
> short-lived branch off of previous releases. If we're talking about only
> having Critical+ issues go into bugfix releases, it should be relatively
> easy to include them for all minor releases in our supported major
> release(s).

I'm not sure I'd add the restriction to "Critical" issues here. I
think what would be included in these would be decided by the release
plan. That may mean that it includes one critical fix and 5 minor bug
fixes, or maybe a roll-up of 20 minor bugfixes. Whatever is decided to
be included, it should be done so by enumerating those fixes in the
release plan, voted on as a majority vote, according to the bylaws.

> I'd also like us to formally define major version lifecycle when we vote on
> a new release plan for that major version. It's probably best if the
> end-of-life is tied to the release of the next major version, so that we
> have more incentive to avoid rapidly doing many major releases.
> There are two other things in Christopher's original message I'd like to
> discuss, but I'm not sure if they'd be better served in a different thread?
> 1) 1.7.0-SNAPSHOT in expectation for a forthcoming minor release
> I don't think we ever finished the discussion of what to do with 1.x once
> we have a 2.x out the door. I'd like to reiterate my concern that mixing
> versioning number schemes in 1.x is confusing. Every other 1.x release in
> the line has been a major release. It will be very hard to break that
> expectation.

While we would be diverging from that expectation, we would not be
breaking anybody who holds that expectation, so I think it's fine to
proceed with minor releases in 1.x until 2.x is released. To clarify,
imagine somebody has that expectation... so they aren't willing to
upgrade to a minor 1.7.0 release. That's fine, they don't have to.
Their upgrade path would only include 1.6.x bugfix releases. However,
if somebody does want a particular feature in 1.7.0, we'd only be
lowering the bar for them to upgrade, by ensuring it stays more
compatible with 1.6.0. I don't see a problem here.

> 2) would have to discuss what kinds of things we'd want in such a release.
> Minimally, I want ACCUMULO-1691
> It's my understanding that ACCUMULO-1691 will break wire compatibility,
> yes? If we're calling 1.7.0 a minor release, I do not want wire
> compatibility broken in a minor release. If we're planning to only include
> critical+ issues on bugfixes, then we need to make sure minor version
> upgrades are low risk.

I do not believe ACCUMULO-1691 needs to break wire compatibility at
all (I bumped the wire version in the patch, to be safe, but I don't
think it needed to be bumped). However, I agree we should discuss
whether wire compatibility can be broken in a minor release. If we
decide it cannot, I think that would have broader negative
implications about being able to bump dependency versions in any minor
release. We can discuss that in another thread, though.

> I know we haven't finished our discussion about what our compatibility
> statement will cover and I'd like to have it in place before we do a
> release under a new versioning scheme (wether or not that includes changing
> the versioning within 1.x).
> On Mon, May 12, 2014 at 10:10 AM, Bill Havanki <>wrote:
>> I like this plan overall. I am definitely in favor of more frequent,
>> lighter-weight bugfix releases. We can start to move toward a regular
>> schedule of them, based on whether there is enough there to warrant one
>> each month / two months / whatever.
>> We could start by branching off 1.6.0 now, and merging in whatever bug fix
>> commits make sense (pending a discussion as Christopher suggested). It can
>> be kept in a ready-to-release condition, for whenever it's "time" for
>> 1.6.1.
>> What about 1.5.x? That will still receive feature changes as well as bug
>> fixes, I assume, until it goes EOL.
>> On Mon, May 12, 2014 at 10:44 AM, Josh Elser <> wrote:
>> > On 5/12/14, 10:41 AM, Keith Turner wrote:
>> >
>> >> On Sun, May 11, 2014 at 6:54 PM, Josh Elser<>
>>  wrote:
>> >>
>> >>  >SGTM. Looks like there aren't currently any fixes of much substance
>> for
>> >>> >1.6.1 presently, but there are a few that would make for a very-low
>> >>> impact
>> >>> >1.6.1, and a good 1.5.2 which also includes the fallout tickets
>> shortly
>> >>> >after 1.5.1. Timeframe looks good to me too.
>> >>> >
>> >>> >If we can get that reduced test burden for "real" bug-fix releases
>> >>> >hammered out, a month sounds good to me.
>> >>>
>> >>
>> >> Rather than reduce the test burden, it would be nice to make the cluster
>> >> testing more automated like you and other have discussed.
>> >>
>> >
>> > I think that would be a good parallel goal, but I would still think that
>> 7
>> > days of testing for a bug-fix release is excessive. Most times for me the
>> > pain is getting resources to test for such a long period, not necessarily
>> > setting up the test.
>> >
>> --
>> // Bill Havanki
>> // Solutions Architect, Cloudera Govt Solutions
>> // 443.686.9283
> --
> Sean

View raw message