Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Europa Maintenance Update Site (was: Re-spin process)

On 7/9/07, Thomas Hallgren <thomas@xxxxxxx> wrote:
> Nick,
> Is site-interim.xml the site where you publish bug fixes for your most
> recent R-build or is this the site where you publish coming work on the
> next minor release?

If I'm not mistaken, you've asked the same thing twice: bug fixes for our
most recent R build (2.3.0) are published under the version 2.3.1... which
will be our next minor release.

So, to reiterate... site.xml contains all our Release (R)  builds from
2.0.x - 2.3.0. site-interim.xml contains everything else -- builds that are
done along the way towards a release, be they a stable/milestone (eg.,
2.3.0M6), an integration build (2.3.0 I20070404000), or a maintenance build
on the current or previous branch (2.2.4 M200707070000, 2.3.1

Regarding your suggestion for "Closed", "Bug fix" and "Fall Update"
streams, I agree with the idea in concept but I think the last two can in
fact be the same thing, since as per my first comment above, the purpose of
the Fall Maintenance *IS* bug fixes, thus for the EMF case, we will be
providing 2.3.1 in October to Europa Fall Maintenance, and providing M
builds along the way weekly to our update site and to Europa as requested.
Because we don't usually do milestones in a maintenance branch, we could
decide to run milestone-like updates (that is, Europa-o-matic respins &
pushes from staging) every 3-4 weeks so that people can get a Fall
Maintenance update/preview and cross-project testing can be done for the .1
stuff as it's been done for the past few months for the .0 stuff.

So, here's my proposal, in terms of URLs:

Europa .0 (the current state of the union):

Europa .1 (Fall Maintenance)

Europa .2 (Winter Maintenance - same URLs as .1)

Ganymede .0 (presumably to start some time after .1 or .2 is done, like
last year)

When /europa/maintenance/ (Fall) is completed, its bits will be moved to
/europa/ so that there will no longer be available the old .0 releases.
(This is what was done for Callisto and AFAIK no one complained that they
could no longer get the .0 versions.) When /europa/maintenance/ (Winter) is
completed, those bits will also be moved to /europa/.

One happy benefit to this is that even though symlinks don't work across
the mirrors, they don't have to. By moving the bits, we:

a) save disk space
b) end up with an empty update site*

* To avoid 404s we'll likely have to put an empty site.xml in there just so
Eclipse will happily scan it and say "no updates available" instead of
puking messily into the .log.

Then, because everyone already has the main site in their Eclipse instance
(because the platform contributes it via their features), they can just
start getting their updates from that site. This is how things work with
EMF/EMFT/MDT/M2T: if you want the bleeding edge interim/maintenance
updates, you have to manually add another update site. Then, when a release
is available, you can get it from the main site.xml which is references in
the features. Old interim/maintenance builds are removed from
site-interim.xml once a release is available to save mirror space; the same
is true here for a /europa/maintenance/ release.

This is how we've done things for the past few years in Modeling-land and
it works pretty well. I only suggest /maintenance/ over site-interim.xml
because it's a simpler URL and it means you can keep the entire sites
separate. For us, we have multiple versions of old jars in the same
features/ and plugins/ folders, with just two site*.xml files to access the
different build types. For Europa, this would work too but as I'm not
familiar w/ the way the Europa-o-matic works or how bits are moved from
staging, I'm just suggesting the option that might be cleaner / easier to


Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling ::

Back to the top