Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Re: Backporting policy proposal
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
> 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
> http://gravatar.com/ctubbsii
>

--
Cheers
~John
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB