Quoting Daniel Eischen <[EMAIL PROTECTED]> (from Tue, 18 Dec 2007
07:32:19 -0500 (EST)):
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.
I asked already something like the following, but haven't seen an
answer, what about:
- RELENG_7_0 with FBSD_1.0
- RELENG_7_1 with FBSD_1_1 in case of an addition
to the ABI
- RELENG_8_0 with FBSD_1.0 and
FBSD_2.x and
FBSD_1.1 in case of an addition
to the ABI in RELENG_7
Bye,
Alexander.
--
The warning message we sent the Russians was a
calculated ambiguity that would be clearly understood.
-- Alexander Haig
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
