incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Re: Branching strategy for Bigtop
Date Tue, 27 Sep 2011 21:52:31 GMT
On 09/27/2011 02:51 PM, Bruno Mahé wrote:
> 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.
>
> Thanks,
> Bruno

Second bullet should be:

* If there is some work which will break trunk or make it UNstable.
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




Mime
View raw message