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

[John Baldwin]

On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote:
> 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.

Yes, but how do you know which ones are interim versions that are safe to be 
removed?  Having separate namespaces makes this clear.

> 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.

You can manage the MFC by making the symbol a "public" symbol and then MFC'ing 
it into the public namespace.  Changing a lot of files is a true point.

> 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.

Note that if you stick on HEAD you won't have a flag day, the flag change is 
on the RELENG_x branch, so only if you are following HEAD and decide to 
follow the new RELENG_x branch rather than staying on HEAD do you have a flag 
day.  That is, if one did a bump to foo at fbsd-current-1.0.1 a week before 
RELENG_12 was branched, then at the time of the branch, 
foo at fbsd-current-1.0.1 gets "tagged" as foo at fbsd-1.1, then in the branch 
foo at fbsd-current-1.0.1 label gets dropped, but in HEAD the 
foo at fbsd-current-1.0.1 label might stick around for 4 months.

The one thing that the simpler case doesn't provide is a clear delineation 
between "extra" versions in the case that one does multiple ABI bumps in 
HEAD.  This really hinges on how often we expect that to happen I guess.  If 
we (collectively) don't expect it to be often, perhaps then the simple policy 
(just use the real versions always, and bump for everything, including this 
fts(3) change) can be used for now, and if we find at some point that we do 
have a lot of extra versions we can then revisit the policy.

Also, one variation based on what Yar said earlier that I hadn't thought of, 
is that we could use fbsd-X.Y.Z as the "private" versions for HEAD if one did 
use the more complicated scheme.  Anyways.

-- 
John Baldwin