SimRel/Simultaneous Release Requirements/Appendix

Simultaneous Release Requirements Appendix

WORK IN PROGRESS - This is not the official document but a staging area for proposed changes. Please see SimRel/Simultaneous_Release_Requirements for the actual official document.

Updated October 2, 2013

Authored and maintained by the Eclipse Planning Council

Contact: David Williams

This document is an appendix to the Simultaneous Release Requirements document, and is intended to provide supplementary information for the primary document. This may be in the form of greater detail or explanations for a stated requirement. It is generally intended to be used as a reference from the primary document, and not read on its own.

Normal Release Requirements

Formal (standard format) plans, early (M4)

Target Environments

It is a similar case for specifying what minimum (or, maximum) Java level to use (such as Java 5, Java 6, Java 7). We do not mandate any particular level, but the question often gets asked, so we simply clarify here that projects should well document what version of Java they generally write to and test with. (Note: individual bundles have their own specific BREE's, but that is a very specific "micro" level specification, and does not reflect the overall level of Java targeted, or tested.)

It would be anticipated that this year, for Kepler, many Eclipse users would still be using Java 6, but projects should test extensively on Java 7. In general, it is recommended to write your code to the lowest level possible, but test on the highest level possible.

Of course, the "target environments" you focus on, in your plans, depends on your project. For example, some runtime projects might focus on what servers they work with and test, some projects might focus on what browsers they target, test, and support, or similar.

To satisfy this requirement, please document your supported platforms in your standard project plan by having a section labeled, exactly, as <target_environments>. See template in standard plan reference and for an example, other than the Platform's, see the subject section in Web Tools plan.

Be sure to raise any "target platform level" questions or issues to the cross-project list, especially if a your project is "moving up" a level and might affect projects or adopters that depend on it.

Compatibility with Previous Releases

Note: this primarily applies to projects that have "released before", but even those releasing for the first time should be aware of this requirement as there could be things done "now" for future compatibility and migration ... these need to be "thought through" even for your first release, to make sure your second release maintains appropriate compatibility.

The intent, here, is for projects to document their intent and whether or not bugs about compatibility would be considered valid. For example, a project might document "we support only a one-time migration of projects, and if it is a shared project, all developers must move to new version at the same time". While that level of compatibility is less than ideal, at least then adopters know what to expect and can make their plans based on that information.