|Re: [ee4j-pmc] Long Term Maintenance|
I think you're asking a history question so let me explain what Sun/Oracle has done...
Each version of the specification is cast in stone. Any change to the specification requirements results in a new version of the specification.
The specification document may be updated using a JCP MR, as described on our web site, to fix things such as typos. Such a change results in a new "rev level" of the document, but does not change the specification - the API signatures are exactly the same, the API semantics are exactly the same, the API requirements are exactly the same.
The javadocs may be updated similarly.
The javadocs sometimes also include information about the current implementation of the API, things that are not required by the spec but that are useful for users of the implementation to know. These can be updated without going through the JCP.
It's not unusual to update a TCK. Tests may be added to the exclude list. Sometimes a test is found to have implementation dependencies or other bugs but is testing important functionality so rather than exclude the test we supply an alternate version of the test. Licensees may use either version of the test.
The Reference Implementations may be updated for all the usual reasons.
All of the above applies to the current versions of the specs.
While we could update an older TCK, there's generally no reason to do so since our TCK license requires licensees to use the current version. (It's a bit more complicated than that.)
And we could fix typos in an older version of the spec, but there's really no motivation to do so.
Older versions of the RI might be updated to fix security problems.
Of course, EE4J can revisit all of these policies.
Wayne Beaton wrote on 11/ 3/17 12:13 PM:
Back to the top