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)
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.
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
IP Documentation and Logs (RC1)
Projects are encouraged to create drafts of the Projects IP Logs even earlier. The development process requires the IP Log to always be accurate, but experience shows there often are not, until examined for a release, and there are typically many issues to resolve, or fixed, before the final submission to the IP staff. For example, sometimes a CQ might have the wrong flag, and cause it to not show up in the Auto IP Log, or perhaps a common, already approved 3rd party jar was was used, but no CQ for that specific project entered one for the new version. The purpose of having these early drafts is so that projects get familiar with what is required, and do not allow work to build up until the ver, since that could cause a "bottleneck" at a critical time and jeopardize having the ability to resolve all issues in time to be released. Also, some adopters will want to look at early drafts to see what 3rd party requirements are associated with the code they are planning to adopt.
A good guideline is to have a draft of your IP Log by M5, and plan for it to be complete for M7.
Note that being in the Simultaneous Release will give your IP CQ requests some higher priority in getting evaluated, in order to make the date. The higher priority treatment is only for the 5 months or so before the release (after the deadline for CQs, typically M5). The reason being, of course, is that the rest of the year the IP staff must also get work done for maintenance releases and projects not on the release train. During that part of the year (roughly July to February every year) all CQs are prioritized in a uniform way. But, there is a deadline for CQs for the yearly release, usually in February, end of M5, to have all required CQs submitted, on file (but not necessarily approved by then).