accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: GIT
Date Wed, 05 Jun 2013 03:35:26 GMT
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

On Tue, Jun 4, 2013 at 10:46 PM, Sean Busbey <> wrote:
> 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.
> --
> Sean

View raw message