accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: GIT
Date Wed, 05 Jun 2013 02:46:53 GMT
On Tue, Jun 4, 2013 at 10:26 PM, Benson Margulies <>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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message