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


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