Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] 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 planning.

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

2)      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 as Europa.

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




From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Monday, July 09, 2007 8:33 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request


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.

Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

07/09/2007 11:17 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, "" <>



Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin         request


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

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:

If you think we should do something else (a separate Fall Maintenance Update Site, separate from the release site), let's talk about that...

- Bjorn

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 behind us.
cross-project-issues-dev mailing list

Back to the top