cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Daniel Eischen]

On Tue, 28 Aug 2007, John Baldwin wrote:
>
> I think this is dead on, yes.  Only comment I would add is that I think
> the "flag days" should be when a new RELENG_X is branched and that all the
> FBSD-current shims get tossed in the RELENG_X branch.  The FBSD-current shims
> can be dropped from HEAD on a separate schedule, maybe where they get dropped
> after they've been around for 6 months or so.  This does mean that stepping
> off -CURRENT onto RELENG_X requires a rebuild of your ports for any symbols
> that changed since RELENG_X-1, but I think that is tolerable.

The only thing I would add is that we can do this by using the
real public versions in -current instead of private ones only
seen in current.  By using the public versions, -current users
will never have to rebuild any of their ports _unless_ the
same ABI changed more than once in -current, and that has
never happened in the past.  If it does happen, you can
remove interim versions from RELENG_X at the branch, and
then remove the interim version from -current some time later.
This is the same approach as using a "private in current"
version namespace.  The only disadvantage is that you might
be missing a version or two in RELENG_X if you remove an
interim FBSD_1.4 for instance.

The other problem with the private version namespace thing
is that it doesn't allow for MFC'ing an ABI change to RELENG_X.
It also causes you to change a lot of files (Symbol.map files,
source files with compat shims) whenever you have the flag
day and move from FBSDcurrent_1.x to FBSD_1.1.

It is so much more simpler to use the same versioning in
-current as for releases.  It is easier to MFC, doesn't
cause unneeded changes to Symbol.map files and compat shims,
doesn't cause -current users to rebuild ports after flag
day (unless there are overlapping ABI changes), and still
provides everything that using the private version namespace
provides.

-- 
DE