Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h

From: Alexander Kabaev <kabaev_at_gmail.com>
Date: Wed, 28 May 2008 13:54:32 -0400
On Wed, 28 May 2008 11:39:21 -0400 (EDT)
Daniel Eischen <deischen_at_freebsd.org> wrote:

> Interesting, as long as "a" = ".1", so that you have FBSD_1.0.1 as
> the side version.
> 
> See my prior email - I thought we agreed that we just MFC the version
> (in this case, FBSD_1.1) from -current.  If you introduce a new
> version, a binary built on 7.x may not run on -current from before
> the side version was added.  For instance, if we were to add
> memfoo() in -current now, then we release 8.0 with memfoo_at__at_FBSD_1.1,
> then after the release we MFC memfoo() to RELENG_7 in the way
> you describe, then anything built in RELENG_7 using memfoo() will
> not work in 8.0 release (because 8.0 didn't have the side version
> memfoo_at__at_FBSD_1.0a/1.0.1).
> 
> Typically before a release there are a flurry of MFCs, so you can
> have a few months or more elapse before the addition of new or
> ABI-changed symbols.  If we just use the same version as -current,
> then things will just work, at least from when the symbol was
> changed/added in -current.

There are number of corners we can cut if we agree that being sloppy is
not a problem. Then why did we bother with symbol versions in the first
place?
 
> But regardless, I think this means that once we release 8.0, we
> cannot MFC any new or changed symbols (from 8.0+) back to
> 7.x.  If someone upgrades from 7.x to 8.0, then 8.0 has to
> have all the symbols that 7.x will have or else binary
> compatibility will be broken.
>
That is why introducing new symbols in back-releases is not such a hot
idea. Release X that was released after release Y cannot really be
expected to be able to execute Y's binaries with 100% certainty, as that
depends on guessing the future right at X ship time.
-- 
Alexander Kabaev

Received on Wed May 28 2008 - 17:54:41 UTC