RE: [Lsb-wg] opposition to LSB 2.0 rc1

["Wichmann, Mats D" <mats dot d dot wichmann at intel dot com>]

Update:

>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.