MMN and branches (was Re: svn commit: r307031)

[Joe Orton <jo...@redhat.com>]

On Sat, Oct 08, 2005 at 04:51:51PM -0500, William Rowe wrote:
> Joe Orton wrote:
> >I'd suggest just incrementing the MMN by one rather than bumping it by 
> >date on the branch unless and until the API is the same as the trunk.
> 
> I previously considered that.  Although you are right; they are out of 
> sync, I think it's inevitable with two branches following different
> history, no?

It's not inevitable but it is the status quo ;)

> This is why the MODULE_MAGIC_COOKIE is now AP24 on svn head, because the
> two branches can't remain binary compatible, at least not except for
> some very short periods of time.
>
> Perhaps you are right, perhaps it's time to drop date stamps as the 
> MODULE_MAGIC_NUMBER_MAJOR signature?

Maintaining an MMN which is intended to reflect every single ABI change 
and multiple branches with independent ABIs is going to be a tricky 
problem.

Alternatives I can see:

a) partition the MMN major by MODULE_MAGIC_COOKIE, so modules
must test an (MODULE_MAGIC_COOKIE, MODULE_MAGIC_NUMBER_MAJOR) pair to 
target a particular API

 -> results are then reliable across history and across branches
 -> icky

b) stop bumping the MMN by date on branches, just increment by one and 
hope that enough gap is left

 -> results are then reliable across branches but not across history

c) don't backport ABI changes to branches; a branch much fork from a 
specific MODULE_MAGIC_NUMBER_MAJOR and must be rebased entirely to move 
to a new major

 -> avoids the problem entirely

d) drop the requirement that the MMN must reflect every single ABI 
change and make some more fundamental change

joe

Re: MMN and branches (was Re: svn commit: r307031)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Orton wrote:
> 
> c) don't backport ABI changes to branches; a branch much fork from a 
> specific MODULE_MAGIC_NUMBER_MAJOR and must be rebased entirely to move 
> to a new major
> 
>  -> avoids the problem entirely

It's always this way on even branches, but we are talking about odd #'ed
branches, here.

> d) drop the requirement that the MMN must reflect every single ABI 
> change and make some more fundamental change

I've always considered the possibility that we only bump MMN major, by
date, exactly once when we roll rev x.y.n <shrug>.

Better idea; let's refactor the whole MMN magic in httpd 3.0?

(It's already looking, from the scope of the experimental asynch branch,
that it's likely to become 3.0.)

Bill