On Tue, 18 Dec 2007, Alfred Perlstein wrote:
* Daniel Eischen <[EMAIL PROTECTED]> [071217 17:42] wrote:
On Mon, 17 Dec 2007, John Baldwin wrote:
On Friday 14 December 2007 03:49:07 pm Daniel Eischen wrote:
deischen 2007-12-14 20:49:07 UTC
FreeBSD src repository
Modified files:
lib/libc Versions.def
Log:
Increment the version namespace for 8.0-current. New symbols and
symbols whose ABI has changed should be added to FBSD_1.1.
Why do new symbols have to be added to 1.1 instead of 1.0?
There is no technical reason they cannot be, but this is what we
decided some time ago. That each time head is branched, a new
version is created and new and ABI-changed symbols get added to
it. It makes it easy to track when (initially in which major
FreeBSD version) symbols get added. I should have also noted
that this was discussed with kan and das (not des) prior to
commit. kan's other comment was that this would also make it
easier to write tools that can tell if an application built on
release X can run on release Y (where Y < X).
We can still MFC new symbols back to prior releases, we just
have to add them to the same namespace from which they came.
Daniel, is there anything preventing us from matching version
numbers with release numbers? This would make things a bit
more intuative.
This was already discussed before. I do not think it is a good
idea - it is easy to create a lookup table matching version
numbers to release numbers if that is needed for ABI checking
tools, and simple comments in the version defs file makes it
apparent to anyone looking at it. I don't think we want to
tie release numbers to version numbers, and when you backport
changes, it makes it confusing because you now have FBSD_8
symbols in releng_7. Other packagers may also not be using
the same release numbering scheme that the project uses.
Sun for instance does not name their versions after releases,
they use SUNW1.0, SUNW_1.1, etc. Also, there may be multiple
ABI changes in HEAD that warrant bumping the version number
more than once (akin to bumping library versions, but this
hasn't yet happened in the past). There would be no
corresponding release to match, but you would have to bump
the version number regardless.
The version numbering is not something that is easily visible
to the user. It is simpler and more flexible to avoid tying
version numbers to release numbers, and to write ABI checking
tools (easily done with scripts) to do what we need.
--
DE
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
