[GiNaC-devel] versions and branches

[Alexei Sheplyakov]

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