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 >> GIT


That's my understanding as well. The main point being that "old
version" branches don't stick around long enough to get stale. After
all, it was created because there was a a bugfix somebody felt was
worth patching... it should be released at some point. In other words,
create the branch for a *purpose* (in this case, to fix and release
some bug fixes) or don't create it at all.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 10:46 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 4, 2013 at 10:26 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:
>
>> > 1.4.4 has been released. The first person finds some changes that should
>> be
>> > placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>> > created from the 1.4.4 tag.
>>
>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>> 1.4.x? On other projects, there's an assumption of one branch per
>> maintained minor version, with point releases as tags along they way.
>> How is your more complex? scheme advantageous?
>>
>
> I believe in this set up, in the absence of 1.4 non-compatible changes in
> flight there would not be a 1.5 related branch unti 1.4.5-SNAPSHOT had been
> tagged and removed.
>
> Thus, when a someone comes in provide a patch for some new bug, there are
> not multiple release branches. I don't see, for example:
>
> * 1.4.x
> * 1.5.x
> * master (1.6.x)
>
> This means that I don't have the opportunity to go "Oh, which of these do I
> put this on?" Instead I have to think:
>
> 1) What isn't end of life? (1.4+)
> 2) Does this break compatibility for that version?
>   2a) no? branch from last 1.4 tag
>   2b) check next most recent release and loop 2
>
> Also implied is that the normal workflow means that tagging e.g 1.4.5 would
> be followed by making a 1.5.1-SNAPSHOT to roll those same fixes up to the
> list of supported versions.
>
> In practice, if there are changes in flight non-compatible across multiple
> supported versions we'll end up with multiple -SNAPSHOT versions at once
> and it will look much like maintaining the 1.y.x branches. However, it will
> be clear that we're in such a state and it will also be clear when things
> collapse back.
>
> --
> Sean
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