Compatibility specifies the portability of binary objects and source code across different instances of a computer operating environment. Officially, Red Hat supports current release and two consecutive prior versions. This means that applications built on Red Hat Enterprise Linux 4 and Red Hat Enterprise Linux 5 will continue to run on Red Hat Enterprise Linux 6 as long as they comply with Red Hat guidelines (using the symbols that have been white-listed, for example).
Red Hat understands that as an enterprise platform, customers rely on long-term deployment of their applications. For this reason, applications built against C/C++ libraries with the help of compatibility libraries continue to be supported for seven years, or ten years with an extended subscription.
Source compatibility enables a body of application source code to be compiled and operate correctly on multiple instances of an operating environment, across one or more hardware architectures, as long as the source code is compiled individually for each specific hardware architecture.
Source compatibility is defined by an Application Programming Interface (API), which is a set of programming interfaces and data structures provided to application developers. The programming syntax of APIs in the C programming language are defined in header files. These header files specify data types and programmatic functions. They are available to programmers for use in their applications, and are implemented by the operating system or libraries. The syntax of APIs are enforced at compile time, or when the application source code is compiled to produce executable binary objectcode.
APIs are classified as:
In all cases, application developers should seek to ensure that any behavior they depend on is described in formal API documentation, so as to avoid introducing dependencies on unspecified implementation specific semantics or even introducing dependencies on bugs in a particular implementation of an API. For example, new releases of the GNU C library are not guaranteed to be compatible with older releases if the old behavior violated a specification.
Red Hat Enterprise Linux by and large seeks to implement source compatibility with a variety of de jure industry standards developed for Unix operating environments. While Red Hat Enterprise Linux does not fully conform to all aspects of these standards, the standards documents do provide a defined set of interfaces, and many components of Red Hat Enterprise Linux track compliance with them (particularly glibc, the GNU C Library, and gcc, the GNU C/C++/Java/Fortran Compiler). There are and will be certain aspects of the standards which are not implemented as required on Linux.
A key set of standards that Red Hat seeks to conform with are those defined by the Austin Common Standards Revision Group (“The Austin Group”).
The Austin Group is a working group formed in 1998 with the aim of unifying earlier Unix standardization efforts including ISO/IEC 99451 and 99452, IEEE Standards 1003.1 and 1003.2 (POSIX), and The Open Group's Single Unix Specification. The goal of The Austin Group is to unify the POSIX, ISO, and SUS standards into a single set of consistent standards. The Austin Group includes members from The Open Group, ISO, IEEE, major Unix vendors, and the open source community. The combined standards issued by The Austin Group carry both the IEEE POSIX designation and The Open Group's Technical Standard designation, and in the future the ISO/IEC designation. More information on The Austin Group is available at http://www.opengroup.com/austin.
Red Hat Enterprise Linux characterizes API compatibility four ways, with the most compatible APIs scored with the smallest number in the following list:
No changes. Consumer should see no visible changes.
Additions only. New structures, fields, header files, and exported interfaces may be added. Otherwise no visible changes allowed.
Additions and Deprecations allowed. Structs, headers, fields, exported interfaces may be marked as deprecated or if previously marked as deprecated the headers, fields, exported interfaces, etc may be removed. Deprecated items may still exist as part of a compatibility layer in versioned libraries for ABI compatibility purposes, but are no longer available in APIs.
Anything goes. No guarantees whatsoever are made.
In the following sections, these API classification levels will be detailed for select components of Red Hat Enterprise Linux.
