Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Backporting policy proposal

Christopher 2013-06-17, 17:07
Billie Rinaldi 2013-06-17, 21:26
Dave Marion 2013-06-17, 22:35
Christopher 2013-06-18, 00:22
Billie Rinaldi 2013-06-18, 13:50
John Vines 2013-06-17, 20:02
Christopher 2013-06-17, 20:59
Copy link to this message
Re: Backporting policy proposal
I should also mention another argument against back-porting features.
With our discussions about documentation, the problem of back-porting
grows worse, because now we need to bombard users with more sets of
documentation that applies to each release. Whereas, if we were more
strict about bugfix releases just being bugfixes, we wouldn't have to
republish documentation. The 1.5 user documentation would apply to all
1.5.x, not just 1.5.0, with new documentation for 1.5.1, and more with
1.5.2, etc.

So, just the problem of keeping users informed of our features,
through documentation, becomes needlessly problematic if we start
back-porting features to older release lines.

Christopher L Tubbs II
On Mon, Jun 17, 2013 at 4:59 PM, Christopher <[EMAIL PROTECTED]> wrote:
> 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
> http://gravatar.com/ctubbsii
> On Mon, Jun 17, 2013 at 4:02 PM, John Vines <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 http://s.apache.org/sU5 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
Adam Fuchs 2013-06-18, 14:53
Christopher 2013-06-18, 17:50
Keith Turner 2013-06-18, 16:05
Mike Drob 2013-06-18, 20:59
Christopher 2013-06-18, 17:55
Keith Turner 2013-06-18, 18:21
Josh Elser 2013-06-18, 15:05
Adam Fuchs 2013-06-18, 15:26
Josh Elser 2013-06-18, 15:43
John Vines 2013-06-18, 15:31
Josh Elser 2013-06-17, 23:35