In message: <[EMAIL PROTECTED]>
Yar Tikhiy <[EMAIL PROTECTED]> writes:
: On Mon, Aug 27, 2007 at 09:30:48PM -0400, Daniel Eischen wrote:
: > On Tue, 28 Aug 2007, Yar Tikhiy wrote:
: > >
: > >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.
: >
: > I think you're a little confused here. CURRENT users did NOT have
: > to rebuild ports when fts(3) or stdio(3) ABIs changed. They
: > would only have to rebuild if one of these ABIs changed _more
: > than once between releases_. That hasn't ever happened to my
: > knowledge in the past, and it really shouldn't happen as long
: > as things are tested and reviewed properly.
:
: Oh, indeed! If a user builds an ABI-dependent port before the
: change, the port will record dependence on say [EMAIL PROTECTED] In
: our example, the default version of fwrite() and friends will change
: to FBSD_1.1 later, after 7.0-RELEASE is out, but [EMAIL PROTECTED]
: will also stay as a compatibility version because it appeared in
: the previous release. Moreover, the port will still work even if
: the ABI component changes once more after 8.0-RELEASE and proceeds
: to FBSD_1.2, because [EMAIL PROTECTED] will be there. Similarly, a
: port built between 7.0-R and 8.0-R will work after the 2nd change
: as [EMAIL PROTECTED] will be there, too.
:
: I can't but remark that this is not a natural effect of symbol
: versioning, but a consequence from the following policy:
:
: - At most one new version is introduced between major releases.
: - Symbol modifications during the period are assigned to the new version.
: - There is exactly one change per symbol per version.
: - All old symbol versions created so far are preserved.
:
: Now we have at least one policy with known behavior. :-)
How is this a natural consequence of this policy? If one were to
bump twice, how would that break it?
Warner
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
