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.
signature.asc
Description: Digital signature
