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

[Yar Tikhiy]

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

-- 
Yar