Home | About | Sematext search-lucene.com search-hadoop.com
 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