Introduction

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.

Backward Compatibility

To achieve backward compatibility, each subsequent version is purely additive--in other words, interfaces are only added, not removed (our interface deprecation policy does provide us with a mechanism for removing interfaces, but only after the interfaces have been marked "deprecated" for at least three major versions, or roughly six years).

The LSB adopted an interface deprecation policy to give application developers enough time in case an interface is removed from the LSB. This allows the developer to rely on every interface in the LSB for a known time and also to plan for changes, without being surprised.

To deprecate an interface in the LSB the following process is used:

• An interface is selected to be depricated by the LSB workgroup
• For the next update of the standard the interface is marked as "deprecated"
• The interface is kept to the end of the 3rd major release following the deprecation
• Then the interface is marked as "removed" and deleted from the standard (but kept in the LSB database)

This policy allows for at least six years of planning horizon for application developers to rely on any given interface in the LSB.

The Roadmap

At a high level, then, the LSB roadmap looks something like this:

 A general roadmap for LSB 4.0 is listed below. For a more technical, up-to-date status of LSB 4.0, please visit the ProjectPlan40 site.

Roadmap for LSB 4.0 (2008)

LSB 4.0 Timeline 14-April-2008

• Feature planning complete

01-August-2008

• Feature Freeze (start bugfixing only)

03-October-2008

• Release of Beta1

31-October-2008

• Release of RC1

11-November-2008

• 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

• Java

• Simpler ways of creating LSB-compliant RPMp packages

• Crypto API (via the Network Secure Sockets library)

Old Roadmaps

Note: Old roadmaps are kept for informational purposes only.

• Roadmap LSB 3.2