Guidelines for backporting

[Stephen Colebourne]

This discussion could do with being written up on the jdk8u pages as
an FAQ or more once complete ;-)

Some use cases:

Performance improvement:
- Change made to code only, no Javadoc change
- No publicly visible API change

Bug fix to match spec
- Spec states behaviour but code doesn't match spec
- Bug fix made to match spec

Bug fix where spec is unclear or ill-defined
- Bug fix made to code that is not against the spec

Spelling mistake in publicly visible Javadoc.
- eg. "tuncation" -> "truncation"

Grammer mistake in publicly visible Javadoc.
- eg. "Subtract a to b" -> "Subtract a from b"

Fixes mistakes in publicly visible Javadoc.
- eg. where the spec part of the Javadoc includes two clashing assertions


This partly resolves to whether the "spec" is the same as Javadoc. I
understand that the spec is not altered once the release is cut, but
does that mean that no changes whatsoever can go into the Javadoc? It
would seem wrong and inefficient to force developers to read mistakes
in Javadoc forevermore because of process reasons...

Stephen



On 18 February 2014 13:42, Seán Coffey <sean.coffey at oracle.com> wrote:
> Stephen,
>
> Joe Darcy laid out some general rules for OpenJDK 6 back in 2008 at
> http://openjdk.java.net/projects/jdk6/ which are equally valid for the JDK
> 8u Project. A suitable interpretation would be :
>
> "As an implementation of the Java SE 8 specification, all changes to JDK 8u
> source code must be allowable within that specification. This requirement
> precludes many API changes. Acceptable API changes include those permitted
> by the 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 would be an upgrade of JAX-WS.
>
> Changes allowable within the Java SE 8 specification may still be rejected
> for inclusion in JDK 8u Project if the behavioral compatibility risk is
> judged as too large. 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 8u too. Examples of
> such universal changes include security fixes and time zone information
> updates.
>
> With the above caveats, bug fixes in JDK 9 that do not involve specification
> changes have presumptive validity for JDK 8u. That is, by default such fixes
> are assumed to be applicable to JDK 8u, especially if having "soaked" in JDK
> 9 for a time without incident.
>
> As a general guideline, if a change is applicable to both 9 and 8u, the
> change should be made in 9 no later than the change is made in 8u."
>
> Have you got more specific questions around specific changes in the pipeline
> ? If people aren't sure about the suitability of certain changes for the JDK
> 8u Project they should certainly air those questions on this mailing list.
>
> regards,
> Sean.
>
>
> On 18/02/2014 10:36, Stephen Colebourne wrote:
>>
>> Is there a page that discusses what should/can be backported (as
>> opposed to how, which does seem to be documented).
>>
>> In particular, I have questions around:
>> - what is the goal of update releases beyond security patches?
>> - what is intended? bug fixes vs performance fixes vs optimisations vs
>> features
>> - can the Javadoc can be changed or not?
>> - what does "no spec changes" really mean?
>>
>> I'm hoping such a page exists already, but I can't find it if it does.
>>
>> Stephen
>
>