[The entry below is a lightly edited version of a
message previously sent to the OpenJDK 6 development alias email@example.com.]
Since questions about OpenJDK 6 processes come up from time to time, in my role as release manager I thought it would be helpful to more fully document the current engineering practices and receive comments about them.
OpenJDK 6 is an implementation of the Java SE 6 specification valuing stability, compatibility, and security. As an implementation of the Java SE 6 specification, all changes to OpenJDK 6 must be allowable within that specification. This requirement precludes many API changes. Acceptable API changes include those permitted by the
title="Java Endorsed Standards Override Mechanism">endorsed standards mechanism, such as upgrading to a newer version of a standalone technology, like a component JSR. One example of such an API change was the
title="OpenJDK 6: Sources for b06 Published">upgrade of JAX-WS from 2.0 to 2.1 in OpenJDK 6 build b06.
Changes allowable within the Java SE 6 specification may still be rejected for inclusion in OpenJDK 6 if the behavioral compatibility risk is judged as too large.
(See previous write-ups of title="Kinds of Compatibility: Source, Binary, and Behavioral">kinds of compatibility and
title="JDK Release Types and Compatibility Regions">compatibly regions in JDK releases.)
Behavioral compatibility concerns implementation properties of the JDK. Clients of the JDK can knowingly or unknowingly come to rely upon implementation-specification behaviors not guaranteed by the specification and care should be taken to not break such applications needlessly. In contrast, if a change is appropriate for every other JDK release train, it is generally appropriate for OpenJDK 6 too. Examples of such universal changes include security fixes and time zone information updates.
With the above caveats, bug fixes in JDK 7 that do not involve specification changes have presumptive validity for OpenJDK 6. That is, by default such fixes are assumed to be applicable to OpenJDK 6, especially if having "soaked" in JDK 7 for a time without incident. On a related point, the fixes from the stabilized HotSpot forests (for
HotSpot Express 14 or
HotSpot Express 16) are suitable for bulk porting to the
OpenJDK 6 HotSpot repository without review of individual bugs.
As a general guideline, if a change is applicable to both JDK 7 and OpenJDK 6, the change should be made in JDK 7 no later than the change is made in OpenJDK 6.
With the exception of security fixes, all OpenJDK 6 code review traffic should be sent to firstname.lastname@example.org for consideration before a commit occurs.
(For subscription instructions and to browse the archives see http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev)
All fixes require the approval of the release manager and may require additional technical review and approval at the discretion of the release manager. Security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to effected JDK release trains.
The master Mercurial forest of OpenJDK 6 repositories resides at:
Since there is only a single master OpenJDK 6 forest, near the end of a build period the release manager may defer otherwise acceptable changes to the start of the next build.†
The schedule to tag builds of OpenJDK 6 is on an as-needed basis. The timing and feature list of a build is coordinated on the jdk6-dev alias with the
IcedTea 6 project, a downstream client of OpenJDK 6. Before a build is tagged, regression and other testing is performed to verify the quality of the build.
After feedback is collected from jdk6-dev and this blog entry, the
OpenJDK 6 project page will be updated with the current process information.
† Alternatively, in JDK 7 there are a hierarchy of staging integration forests under the master to manage a higher rate of change, see OpenJDK Mercurial Wheel). As the rate of change in OpenJDK 6 is comparatively small, as long as the end of build quiet periods continue to be acceptably short, having a single master forest should be simpler than starting and managing an intermediate staging forest kept open to accepting changes at all times.