The LSB aims to provide a "highest common denominator" across the various Linux distributions---in other words, to provide a single target for ISVs writing or porting to the Linux platform, where "the Linux platform" is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run.
To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, ... compliant distributions).
To satisfy the "easy mapping" requirement, each major version of the LSB corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the previous generation (Red Hat Enterprise Linux 4, SUSE Linux Enterprise 9, etc.), wherreas LSB 4.x corresponds to the current generation (RHEL 5, SLE 10, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions.
At a high level, then, the LSB roadmap looks something like this:
|LSB 3.x (2006-2008)||LSB 4.x (2008-2010)|
Roadmap for LSB 4.0 (2008)
LSB 4.0 Timeline
- Feature planning complete
- Feature Freeze (start bugfixing only)
- Release of Beta1
- Release of RC1
- Release of LSB 4.0
Feature plans for LSB 4.0
- glibc 2.4
- Binary compatibility with LSB 3.x
- Easier to use SDK
- Support for newer versions of GtK and Cairo graphial libraries
- Simpler ways of creating LSB-compliant RPMp packages
- Crypto API (via the Network Secure Sockets library)
Note: Old roadmaps are kept for informational purposes only.