This is the mail archive of the
mailing list for the libstdc++ project.
RE: [Lsb-wg] opposition to LSB 2.0 rc1
- From: "Wichmann, Mats D" <mats dot d dot wichmann at intel dot com>
- To: "Alan Cox" <alan at lxorguk dot ukuu dot org dot uk>
- Cc: "Joe Buck" <Joe dot Buck at synopsys dot COM>, <libstdc++ at gcc dot gnu dot org>, <gcc at gcc dot gnu dot org>
- Date: Fri, 6 Aug 2004 17:13:11 -0700
- Subject: RE: [Lsb-wg] opposition to LSB 2.0 rc1
>The "stopgap" or some marketing equivalent of that is
>important IMHO. As is not sticking stopgaps into ISO submissions.
>Call it "stopgap" call it "interim" call it "oh shit" I don't care, but
>recognize the importance of the message please.
After the LSB workgroup meeting the last two days,
the new proposal is to move the current C++ to a module
which will still be required for LSB 2.0 but which will
not be submitted to ISO.
The LSB will quickly transition to the next C++ ABI
and release that as part of an LSB 3.0, as well as
promoting this new C++ module, after it is sufficiently
mature and complete, to the ISO process as an addendum.
This has the additional advantage of allowing the C++
submission to be considered separately, on its own
merits. We'll be asking for some help to make sure
this is done right, is testable, etc. Packaging C++
as a module and publishing this transition plan is
essentially the "message".
A downside of this is that LSB 2.0 will be followed
rather quickly by a 3.0; faster than we'd normally
like. It's really 2.0 that's out of cycle, the new
target of a 3.0 around Q1 '05 looks like a reasonable
progression in time for two releases beyond LSB 1.3.
Despite the short gap, there's value to an LSB 2.0
based on the 3.3 abi, it matches most deployments
we know about for the rest of this year (including
the impending Debian release) and probably a number
off into next year, those releases will naturally
continue to be supported for some time and there are
developers who want to begin building LSB software
now which can be shipped for such systems. It also
gives the opportunity for the eventual candidate for
ISO submission to be the second version of an LSB C++
spec, which is a more comfortable level of maturity.
Thanks to all of those who have given valuable
input into this process.