incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <>
Subject Re: Branching strategy for Bigtop
Date Tue, 27 Sep 2011 21:51:02 GMT
On 09/26/2011 09:08 AM, 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.

My take on it is probably simple:
* trunk should be in a releasable state
* If there is some work which will break trunk or make it stable.
Provided it is a finite amount of work with a known timeline for
stabilization, I am ok to put it in trunk with optionally making a
release just before introducing these changes
* If there are more unknowns to the work, a branch would be more appropriate

In this case, if we have some guarantees regarding hadoop-0.22 and the
associated integration work, I would be ok for using trunk. But I would
really prefer to get a release of bigtop out before that.
Trunk has had a lot of improvements since 0.0.1 and we should make a
release for hadoop 0.20.2 before jumping to the next version of hadoop.


View raw message