On Friday 24 August 2007 07:22:12 pm Warner Losh wrote:
> What's the overhead of having the transition crutch around for a
> while? The benefit is that people are less likely to screw up their
> systems at a time when we want to encourage people to upgrade so they
> can test the latest/greatest version. If it were 9 months after
> RELENG_6 was branched, and a long time to a release, then I'd be much
> more inclined to agree with the 'current is hard, so why spend
> engineering effort on making it easy' crowd than I would now that more
> of the world is watching and using it since we're in the glide path to
> I don't see why we can't put the versioned symbols in, let everybody
> upgrade and then remove the old symbols after a big enough window has
> passed. It isn't like they are hurting anything by being there, is
Then why didn't we bump libc multiple times in a branch? It's the same
exact thing except more fine-grained. If it's ok to bump symbol
versions multiple times (remember, we've already done 1 bump by adding
versioning and going to libc.so.7) in a branch, then it should have been
ok to bump libc major numbers multiple times.
I agree with Dan that we are trying to build releases, and folks running
-current are expected to tolerate change during the current branch.
I wouldn't expect more users until we actually do release BETA1, so I
would go ahead and commit the new fts(3) soon so it is in BETA1 and
the RELENG_7 branch when it is branched.
> If there is some actual harm here, it hasn't been clearly articulated
> and needs to be if that's the case. I'm certainly open to this
I think it will be confusing to have missing symbols just as folks would
have thought it confusing to have 6.x ship with libc.so.8 if we had
bumped libc multiple times. I also think that just managing the
interfaces that show up in releases and -stable branches will be enough
extra bookkeeping to keep track of as it is.