Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SimRel/Simultaneous Release Requirements/Appendix"

Line 33: Line 33:
  
 
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.
 
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.
 +
 +
=== 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).

Revision as of 11:17, 2 October 2013

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.

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).

Back to the top