On Wed, 28 May 2008 11:39:21 -0400 (EDT) Daniel Eischen <[EMAIL PROTECTED]> 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@@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@@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
signature.asc
Description: PGP signature