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
> * 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
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
> I will release what is in the current 2.0 branch as 2.0.1 this weekend.
Get latest updates about Open Source Projects, Conferences and News.