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