[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Mik
Sent: Monday, July 09, 2007 9:26 AM
To: 'Cross project issues'
Cc: 'Mylyn developer discussions'; 'eclipse.org-planning-council';
Subject: [eclipse.org-planning-council] RE: [cross-project-issues-dev]
Re-spin process / DSDP-TM Re-spin request
+1 for increased frequency and figuring out how to coordinate
this with EPP. Here is Mylyn's point of view.
Since we are part of the EPP distros it would be good to have a
well-defined mechanism and process for getting the latest and greatest to users
via EPP while supporting the Ganymede train and Europa maintenance
releases. Current constraints we see:
Platform and other core projects get adopted every 6 weeks by
early adopters, but only yearly by the majority. As long as automatic
update checking is not turned on by default we cannot count on majority users
getting new versions via update sites.
Some projects like Mylyn are evolving rapidly and ensure that
majority users are always best off using the latest.
Many or most integrators don't want to port more than once a
year, whereas we foresee the need to make breaking API changes, i.e. moving
from 2.0 to 3.0, at some point during the Ganymede cycle.
Maintaining more than two streams is a pain.
Here's our current idea for how to accommodate these
constraints, and I'm wondering how this fits for other projects and Europa/Ganymede/EPP
Support Platform 3.3 and 3.4 with a single stream for as long as
possible, branch when necessary. This means that we will be releasing the
same version for the Ganymede train and Europa updates. (We have used
this scheme the past couple of years and ended up branching around Platform M4
each time because we are quite dependent on internals and API additions).
Follow the 6 week schedule but make releases available to
majority users on a quarterly basis, i.e. every other Ganymede release.
For Mylyn this would mean something like the following post-Europa schedule:
Week 6: Mylyn 2.1M (pushed to Mylyn update site only, i.e. can
only count on early adopters getting it)
Week 12: Mylyn 2.1 (pushed to Europa/Ganymede/EPP sites)
Week 18: Mylyn 2.2M
Week 24: Mylyn 2.2
Week 30: Mylyn 2.3M
Week 36: Mylyn 2.3
Week 42: Mylyn 3.0 RC0 (incorporate API changes)
Weeks 48-52: Mylyn 3.0 (final)
Effects of this would be:
EPP could incorporate Mylyn updates once per quarter ensuring that
the majority of users can work from the latest and greatest.
The “2.x” releases would have the same quality bar
The “2.xM” would allow us to get feedback on UI
changes from early adopters before releasing them to majority users.
Integrators only have to port once at the end of the cycle, at
the same time that they would be moving to the 3.4 Platform.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John
Sent: Monday, July 09, 2007 8:33 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Re-spin process / DSDP-TM
Using the same
update site makes sense to me. I guess the question then is how often the
staging site is migrated to the release site. Did this only happen twice for
Callisto (once in the fall and once in the winter)? Perhaps this frequency
needs to be increased to accomodate the various release rhythms of the projects
involved. The other important element in the coordinated release is the EPP
packages. I would love to see a well known place for staging the EPP bits, so
we can invite the community to grab the latest packages and participate in
testing prior to release dates.
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
project issues <cross-project-issues-dev@xxxxxxxxxxx>, "eclipse.org-planning-council"
[cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin
My plan for the Europa Fall Maintenance Update Site was to use the same update
site as the Europa release - I think that's what we did for Callisto and it
makes sense for Europa as well. We'll Europa-matic build into the Europa
staging site (as we did for the major release) until we are collectively happy
with the bits and then we will upgrade those staging site bits to the release
I am already doing Europa-matic builds for the maintenance release (or the
re-spin, or whatever we decide): the results are in the usual place: http://dash.eclipse.org/~bfreeman/europa/
If you think we should do something else (a separate Fall Maintenance
Update Site, separate from the release site), let's talk about that...
John Arthorne wrote:
I think this
debate about respins is only happening because we don't yet have the Europa
fall update site set up yet. In the absence of this, Europa respins are
the only way to get our critical fixes out there. I suggest we create a Europa
fall update site as soon as possible so we can put the Europa June 29th release
cross-project-issues-dev mailing list