accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Backporting policy proposal
Date Mon, 17 Jun 2013 20:59:11 GMT
Our versioning standard has been for quite some time now, the standard
Maven [major].[minor].[bugfix] versioning model. While we've perhaps
never really followed this strictly with regards to injecting "minor"
features into a bugfix version, it's a good model to follow, and my
proposal here would turn that "loosely followed" standard into a more
strict standard.

This standard is already reflected in our workflow, after all... we
release A.A.0 versions, and then move on to working on the next
feature release A.B.0, while supporting A.A.x through bugfixes A.A.1,
A.A.2, etc... This workflow implies that the last part of the A.B.C
version is for bugfixes to supported releases. We just haven't
followed this strictly. I'm hoping we do.

Following this strictly means that "minor" features should be avoided
in bugfix releases also, and that bugfixes should really be targeted
to fix the bug without changing the overall feature set or the API or
behavior for existing features.

The kinds of cases like "bugs that are best resolved via a feature"
seem to be very much the kind that we'd want to vote on (and would
fall cleanly into sections 4 and 5 of my above proposal).

Christopher L Tubbs II

On Mon, Jun 17, 2013 at 4:02 PM, John Vines <> wrote:
> I think the issue here is that there is ambiguity on what a minor release
> (minor minor?) is. Will 1.5.1 be only bugfixes, or are minor features
> acceptable? If the former, what about bugs that are best resolved via
> feature? If the latter, where is the line?
> On Mon, Jun 17, 2013 at 1:07 PM, Christopher <> wrote:
>> I propose we adopt a more structured policy beyond simple "lazy
>> consensus" to be apply to backporting features. Some guidelines I'd
>> like to see in this policy, include:
>> 1. Back-porting bugfixes to a prior release line that is not EOL
>> (end-of-life) is always okay (subject to normal lazy consensus), but
>> it is strongly preferred to fix it first in the older branch and merge
>> forward to the newer one(s).
>> 2. Back-porting performance improvements to a prior release line that
>> is not EOL (end-of-life) is usually okay (subject to normal lazy
>> consensus), so long as it does not change user-facing behavior or API.
>> It is still strongly preferred to add such fixes in the older branch
>> first, and merge forward to the newer one(s).
>> 3. Back-porting new features and additions are to be avoided as a
>> general rule (see arguments for this in previous threads:
>> ACCUMULO-1488 and and probably others).
>> 4. If it is desired to back-port a new feature, then a vote on the
>> developer mailing list should be called, due to the additional
>> development and support burden the new feature may cause for all
>> developers.
>> 5. Even when it is agreed that a feature should be back-ported, it
>> should not be done unless/until a feature is first represented in a
>> newer release that has gone through the testing and release process,
>> and can be considered stable enough to back-port. This ensures focus
>> is kept on the main development branch for new features, and
>> significantly reduces the development burden of back-porting. It also
>> gives us a clear idea of the target behavior for the back-ported
>> feature, so that it will behave in the same way as the same feature in
>> the later release line.
>> Please discuss these points, or add your own.
>> --
>> Christopher L Tubbs II
> --
> Cheers
> ~John

View raw message