* Our current policy statement on "new releases" joining a SR maintenance release is in our [[SimRel/Simultaneous_Release_FAQ#Policy_FAQs|Policy FAQs]]. Eventually that's the part we'll want to "tighten up". Must balance flexibility (agility) with stability. Perhaps something similar to "The new release must be in RC1 builds for the SR, must have released one month prior to that RC1, and must be willing/able to test and provide a quick maintenance release if last minute problems found."

+

+

: ''We didn't want to make a decision at this meeting, since wanted to be sure we were considering the "big picture" and not reacting to one case, but came up with the following items:''

+

+

:: ''Seemed reasonable to everyone that, if we keep our current policy, "minor updates must be in fully in by RC1" or else too late to join.''

+

:: ''Should we even allow minor updates at all? What do adopters expect/want from SR releases? Pure maintenance, or new features too?''

:: ''Should whether or not in EPP packages be part of one of the factors? Seems that's where most stability is important/expected, since those users don't have a "choice" to move up to a particular version, they get it automatically.''

+

:: ''As an aside, even Mylyn no longer does minor updates in SRs ... they've stabilized enough not to need it, and recognize they are a core piece of several EPP packages, so more important to be stable.''

== Kepler ==

== Kepler ==

Line 144:

Line 154:

* Issues?

* Issues?

+

: ''None stated.''

+

* Are people "building against" the Platform's Maven/Tycho builds?

−

== EclipseCon face-to-face ==

+

:''No one said "yes". Should send reminder (near time to put warm up in staging).''

−

:Sunday, 2 to 4, following by "joint meeting" with Arch. Council, from 4 to 5.

+

== EclipseCon face-to-face ==

−

* Who is planning to attend? (Please list name, with "yes", "no", "indefinite").

+

:Sunday, 2 to 4, following by "joint meeting" with Arch. Council, from 4 to 5.

+

*Agenda topics? (Please list ideas, so we know ahead of time what's desired).

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

Juno SR2

Any post-release feedback? (Or, too early yet?)

Our current policy statement on "new releases" joining a SR maintenance release is in our Policy FAQs. Eventually that's the part we'll want to "tighten up". Must balance flexibility (agility) with stability. Perhaps something similar to "The new release must be in RC1 builds for the SR, must have released one month prior to that RC1, and must be willing/able to test and provide a quick maintenance release if last minute problems found."

We didn't want to make a decision at this meeting, since wanted to be sure we were considering the "big picture" and not reacting to one case, but came up with the following items:

Seemed reasonable to everyone that, if we keep our current policy, "minor updates must be in fully in by RC1" or else too late to join.

Should we even allow minor updates at all? What do adopters expect/want from SR releases? Pure maintenance, or new features too?

We don't say so, but "no major changes allowed" seems reasonable. That is, no API breaking changes. Sometime, "version ranges", even minor, in theory could be a "breaking change" (though, not exactly API).

Should whether or not in EPP packages be part of one of the factors? Seems that's where most stability is important/expected, since those users don't have a "choice" to move up to a particular version, they get it automatically.

As an aside, even Mylyn no longer does minor updates in SRs ... they've stabilized enough not to need it, and recognize they are a core piece of several EPP packages, so more important to be stable.

Kepler

M6

Issues?

None stated.

Are people "building against" the Platform's Maven/Tycho builds?

No one said "yes". Should send reminder (near time to put warm up in staging).

EclipseCon face-to-face

Sunday, 2 to 4, following by "joint meeting" with Arch. Council, from 4 to 5.

Agenda topics? (Please list ideas, so we know ahead of time what's desired).

Several good ideas were mentioned.

Decide SR Policy.

Should Rt have their own "repo"? Their own Sim Rel Rules? How can the value to them be increased?

What relationship is there (should there be) between OSGi/p2 common repo and Maven/Maven Repos?

Who is planning to attend? (Please fill in with "yes" (Y), "no" (N), "indefinite" (I), the later being you haven't decided yet, or depends on tight plane schedule being on time, etc.).