Hi Jens, On Fri, Dec 10, 2010 at 12:43:52PM +0100, Jens Vollinga wrote:
I try to give a better example than last time for what I think is a disadvantage:
Up to now somebody can pull or checkout ginac_1-5 and will always get the latest ABI-compatible code for 1.5.x.
This is not completely true, sometimes ABI get broken even in "stable" branch(es), sometimes the code won't even compile (see e.g. the commit eaf81b311569), etc.
If we merge, 1.5.x will suddenly be on master, and one would have to monitor any commits on master then for their relevance to 1.5.x.
Then somebody commits an ABI-breaking patch and we would have to recreate another branch for the "new" 1.5.x code.
No, we won't create any branches just because of the ABI changes. Instead we update the version info (ginac_lt_current, ginac_lt_age, ginac_lt_revision) *just before making the release*, and that's it. This doesn't mean we'll break ABI at whim.
Do I understand correctly that we should only commit to master from now on and not create any new branches?
Yes, almost. We might create (short-living) branches for developing $some_feature (a.k.a. `topic branches'), and merge them into master again, when $that_feature is ready for release (example: msvc.support branch). Again, this doesn't mean we should create such a branch for every single feature.
Would that mean that we don't fix bugs in older ABI-branches anymore,
We don't really have manpower to do this anyway, do we?
i.e. leave it to say the debian people to backport bug fixes?
We'd better tell them to upgrade to the newest version. Best regards, Alexei