Arnold Krille wrote:
> On Saturday 05 December 2009 17:27:33 Pieter Palmers wrote:
>> I would like to propose the following strategy:
>> * 2.0-ongoing is only for bug-fixes. No added functionality or
>> significant rewrites. We'll regularly release 2.0.x versions from this
>> if required. We try to keep the number of commits to an absolute minimum
>> on this branch.
> I would not say minimum but "bugfixing only" as fixing bugs is a good thing in
> the branch:-)
Only if the bugfixes don't require massive changes. If that's the case,
I don't think it's a good idea to do this in an 'ongoing' branch.
It's better to fix these in the trunk and make a new major release.
>> * major developments are done in branches from trunk until they have
>> some releasable maturity. This means e.g. that the RME / saffire pro
>> developments should really be in a separate branch. Once they are ready
>> for the (beta) public they can be merged into the trunk. This will avoid
>> the situation we have in 2.0 where the unfinished functionality had to
>> be (e.g. DICE) stripped.
> Yeah, well. Trunk is kind of meant to be broken. Not broken in the sense that
> incomplete commits happen, but that some minor features might not always work
> as expected.
We have to release more often (understatement of the year ;). This means
that we need more control over the quality of the codebase. So I would
prefer a repository strategy where we try to ensure that trunk is always
in a releaseable state (testing).
> Saffire (dice-based) for example is not breaking anything. Its only extending
> support for special devices. Basic support is always working...
> But for new core-features that break one or all platforms completely and are
> not finished withing one commit, I would advice to create development branches
> in /branches/work...
Agreed. I think though that it's better to branch too often than too little.
>> I will release what is in the current 2.0 branch as 2.0.1 this weekend.
It's about time...