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

[John Baldwin]

On Monday 27 August 2007 08:48:42 pm Yar Tikhiy wrote:
> On Mon, Aug 27, 2007 at 06:01:22PM -0400, Daniel Eischen wrote:
> > On Mon, 27 Aug 2007, John Baldwin wrote:
> > 
> > >On Monday 27 August 2007 05:38:08 pm Daniel Eischen wrote:
> > >>>>it is today.
> > >>>
> > >>>So you want to just bump the version everytime a change happens in 
HEAD?
> > >>
> > >>No, I don't see how you get that from what I said...
> > >
> > >You originally objected to having fts compat symbols as 1.0 and wanted 
the 
> > >new
> > >fts to be 1.0.  Now you are saying that the new fts can be 1.1 and the 
old
> > >ones (only used in old current) can remain 1.0.
> > >
> > >That is, now you are saying to do what Yar originally wanted to do before 
> > >you
> > >objected.
> > 
> > No, I still think they should be 1.0 or wait till after the
> > release.  I just made some assumption for the sake of giving
> > an example.
> 
> It's time to summarize previous discussion to prevent further
> misunderstanding. :-)
> 
> Let's recall the point all sides of this discussion seem to share:
> symbol versions can give us ability to run binaries from a former
> _release_ in a later _release_ without installing compat libraries.
> Obviously, it will be available only after 7.0-RELEASE, the first
> release with symbol versioning.  _If this ability is the only goal_,
> Daniel's position makes sense as it implies a minimal number of
> distinct version labels and compatibility shims to support later.
> I.e., we allow new version labels only after 7.0-RELEASE and we
> allow at most one new version label for each successive major
> release.  That's how we make sure that every old version of a symbol
> appeared in at least one former release, so that we don't have to
> support old versions without release history.
> 
> I say "version label" to emphasize the fact that the same version
> strings of different symbols can correspond to totally unrelated
> changes in them, which Daniel pointed out already.  I.e., each
> symbol can travel along the version axis independently.  Moreover,
> it's technically possible to have a separate version axis for as
> little as each symbol, but it would be gross.
> 
> Example: Assume we released 7.0-R with all symbols at FBSD_1.0.
> Before the 8.0 release cycle starts, struct FTS and struct FILE
> change, perhaps a few times each, thus affecting the fts(3) and
> stdio(3) global symbols.  At the very first change to a symbol or
> their group, its 7.0-R variant is preserved at FBSD_1.0 and its
> default version becomes FBSD_1.1.  Later changes to the current
> variant of that symbol don't affect its version.  Consequently,
> 8.0-R is released with the new fts(3) and stdio(3) symbols at
> FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols
> still at FBSD_1.0 because they are unchanged.  Let's note that
> CURRENT users had to rebuild ports depending on fts(3) or stdio(3)
> _each time_ an ABI component changed.
> 
> Now let's see if we can help CURRENT users without putting too much
> burden on our own back.  That's where John's idea comes into play.
> When a symbol changes in 8-CURRENT for the first time, it gets
> promoted from FBSD_1.0 to, say, FBSD-current_1.0.1 while its 7.0-R
> variant is preserved at FBSD_1.0.  If the same symbol or group of
> symbols has to change again and providing compatibility isn't too
> expensive, there appear 2 compat versions for it, FBSD_1.0 and
> FBSD-current_1.0.1, and 1 default version, FBSD_current-1.0.2.  So
> CURRENT users can keep older ports dependent on the intermediate
> symbol(s).  Just before the RELENG_8 branch, all default
> FBSD-current_1.0.* symbol versions, if any, are flattened into a
> single version, FBSD_1.1, while any compatibility shims at
> FBSD-current_* are dropped.  So we end up with exactly the same
> 8.0-R library as in the previous example and from now on we have
> to support only one old variant (7.0-R) of each symbol changed since
> 7.0-R.  The flattening of FBSD-current_* versions will be a flag
> day for port users, but they'll have to rebuild affected ports only
> once.  Unfortunately, even those who built a dependent port a moment
> before the flag day will have to rebuild it after the flag day.
> Therefore we should recall how often multiple changes to the same
> ABI component happened between a pair of successive major releases
> to justify this approach.  We can keep the last FBSD-current_1.0.*
> symbols as aliases for FBSD_1.1 symbols in HEAD for a while, but
> it means greater support burden and dependent ports still need
> to be eventually rebuilt.  Perhaps this is a way to go only in
> case multiple changes to the same ABI component are really likely
> to happen.
> 
> As for committing new FBSD_1.1 versions of the fts(3) symbols right
> now, there's nothing wrong with it technically, but it would set a
> poor example of having old symbols around that have never been in
> a release.  Note that releases prior to 7.0 don't count here because
> "fts_open" != "fts_open at FBSD_1.0".
> 
> I hope I didn't misinterpret any ideas. :-)

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.

-- 
John Baldwin