bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Branching strategy for Bigtop
Date Wed, 28 Sep 2011 05:12:00 GMT
Roman,

I think the branching strategy should be the same as we imagined/used when you
and I started working on the BigTop's foundation - iTest framework and stack
concept.

Here's what it was IIRC (please correct me if I am missing something);
  - whenever you need to work on a specific stack release (say 0.22 based
    Hadoop stack) you branch to reflect whatever specific modifications need
    to be put in there
  - Trunk should be used for development of the framework itself, thus it will
    be used for current rapid development and might be roughly aligned
    with components' trunks as well (or the latest in-release versions of the
    components). 
  - branches can be cut from any point of the trunk (or perhaps other
    branches) depending on the need

Hope it still makes sense as it used to last year ;)
  Cos

On Mon, Sep 26, 2011 at 09:08AM, Roman Shaposhnik wrote:
> Now that the work on incroparating the upcoming Hadoop 0.22 and
> Hadoop 0.23 releases into Bigtop has started I've got a question
> on what makes the most sense from a branching strategy point
> of view. For example, it is pretty clear to me that the work
> for 0.23 belongs in a separate branch in Bigtop. After all,
> that code will be used no sooner than Bigtop 0.3.0.
> 
> By that same logic one could say that the work on 0.22 also belongs
> to a dediacted branch. I'm cool with that, but then I'm not quite
> sure what status will trunk have.
> 
> IOW, what is our policy to trunk commits? Do we only commit things
> into the trunk that can rely on properly released apache projects,
> or will it make sense for us to be a tad more aggressive and commit
> things that we *hope* will make it to the next release (0.2.0 in this
> particular case)?
> 
> Thoughts?
> 
> Thanks,
> Roman.

Mime
View raw message