''It was was suggested we have a FAQ to document this, and to make it clear, those projects still need to have a "release review" per normal EDP rules. It is up to the project to initiate that release review, and up to their PMC to "monitor" (all) their projects to make sure they are following the Eclipse rules, but, as with any other Eclipse Citizen, if the Planning Council happens to notice someone might be breaking the EDP rules, we can certainly point that out to them or the PC rep. The "new content" in SR can be completely new, or possibly a minor bump in feature versions. The FAQ should also strongly word the new content must still meet all the other requirements of the Simultaneous Release, such as signed, externalized strings, etc. In fact, the "requirement" that a project "do no harm" might, in practice, rule out some "low level" features from a having a minor version increase in the common repository. In other words, adding a "leaf" project is relatively easy, changing a low level one requires lot of communication, checking, and testing. [dw agreed to write the FAQ for PC to review]''

''It was was suggested we have a FAQ to document this, and to make it clear, those projects still need to have a "release review" per normal EDP rules. It is up to the project to initiate that release review, and up to their PMC to "monitor" (all) their projects to make sure they are following the Eclipse rules, but, as with any other Eclipse Citizen, if the Planning Council happens to notice someone might be breaking the EDP rules, we can certainly point that out to them or the PC rep. The "new content" in SR can be completely new, or possibly a minor bump in feature versions. The FAQ should also strongly word the new content must still meet all the other requirements of the Simultaneous Release, such as signed, externalized strings, etc. In fact, the "requirement" that a project "do no harm" might, in practice, rule out some "low level" features from a having a minor version increase in the common repository. In other words, adding a "leaf" project is relatively easy, changing a low level one requires lot of communication, checking, and testing. [dw agreed to write the FAQ for PC to review]''

+

+

''New FAQ written at [[SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F | Can a new project or feature join a Simultaneous Service Release (SR1 or SR2)?]]''

''It was agreed we would put the extra week in M6, this year. Another advantage mentioned is that that is API freeze milestone, so if "extra time" is available, that'd be a good place for it. It does put the end of M6 right up to the Friday before EclipseCon. That's good in that it might allow fixes to be made to M6 as people prepare their EclipseCon demos, tutorials, etc. but also has the disadvantage of having "breaks" right before EclispeCon, and also people not being able to get "clean" M6 copies before EclipseCon. Pros and Cons balance, was the collective view. It has actually been "the Friday before EclipseCon" for several years ... though, it did used to be a week earlier. We will leave the open for one week in case others have comments/concerns, then consider it final after 8/10''.

Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Announcements

Indigo SR1

On the topic of "Can new things show up in Sim. Release Service Releases?" ... we have previously agreed "yes". Any discussion?

It was was suggested we have a FAQ to document this, and to make it clear, those projects still need to have a "release review" per normal EDP rules. It is up to the project to initiate that release review, and up to their PMC to "monitor" (all) their projects to make sure they are following the Eclipse rules, but, as with any other Eclipse Citizen, if the Planning Council happens to notice someone might be breaking the EDP rules, we can certainly point that out to them or the PC rep. The "new content" in SR can be completely new, or possibly a minor bump in feature versions. The FAQ should also strongly word the new content must still meet all the other requirements of the Simultaneous Release, such as signed, externalized strings, etc. In fact, the "requirement" that a project "do no harm" might, in practice, rule out some "low level" features from a having a minor version increase in the common repository. In other words, adding a "leaf" project is relatively easy, changing a low level one requires lot of communication, checking, and testing. [dw agreed to write the FAQ for PC to review]

It was agreed we would put the extra week in M6, this year. Another advantage mentioned is that that is API freeze milestone, so if "extra time" is available, that'd be a good place for it. It does put the end of M6 right up to the Friday before EclipseCon. That's good in that it might allow fixes to be made to M6 as people prepare their EclipseCon demos, tutorials, etc. but also has the disadvantage of having "breaks" right before EclispeCon, and also people not being able to get "clean" M6 copies before EclipseCon. Pros and Cons balance, was the collective view. It has actually been "the Friday before EclipseCon" for several years ... though, it did used to be a week earlier. We will leave the open for one week in case others have comments/concerns, then consider it final after 8/10.

Juno Requirements

4.2 vs. 3.8

We will have 4.2 as primary (hence the one used for EPP Packages) but ask participating projects to have a clear plan item titled, exactly, "Support for Eclipse 3.8 workbench" where possible descriptions might be similar to:

Not at all. No support for 3.8 based apps.

We will accept bugs against 3.8 based apps, but do not test or compile against it.

We will compile against and somewhat test 3.8, though 4.2 is primary.

We will support 3.8 as well as 4.2, but the exact functionality may differ.