Yes, this sounds like a good approach.
The only downside I see with this strategy is that the update site
is available early without having any mirrors. I know that in the
past, when we have uploaded a maintenance release without freezing, the
number of update jar requests to eclipse.org have been problematic. I
don't know if this is still an issue.
<Martin.Oberhuber@xxxxxxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
02/28/2008 11:31 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
[cross-project-issues-dev] An alternative
to freezing download.eclipse.org ?
being in Winter Maintenance endgame, this is probably not
the best time for a new suggestion, but it recently hit me
that the way we currently work with renaming builds seems
less than optimal:
* release candidate builds are announced with their old
names plus information what the new name will be
* release engineers patch their build scripts to ensure
that their future builds will have information where
to get proper prerequisites... based on information
about the future...
* download.eclipse.org is frozen for mirrors to pick
all this requires quite a bit of manual work, and seems
like an awkward workflow.
So what is my suggestion? - Here is what's been working
find for us in DSDP-TM and I'm wondering whether this might
be appropriate for other projects as well:
* The overall TM Downloads Page is a dynamic php page
(stolen from GMF, thanks Rich :-) which lists available
* Downloads are only listed when PHP finds them "proper",
i.e. a magic little file "package.count" must be there
* When we're done with a release candidate, it gets its
final name right away (R-2.0.3-200802251530) and is put
in its final location
package.properties is not put there (or renamed to a
different temporary name).
--> That way, anybody who "knows" (via cross-project mailing
list for instance) where the release candidate is, can
already download it. This includes the mirrors, of course.
--> BUT ordinary users still won't see the bits on the download
page until that single little file "package.count" is
That way, everything goes into its right place from the beginning,
dependent projects can consume it from the right place, and there
is no need for server freezing. Would that be an option for
future milestones and releases? If you think there is a flaw
in this procedure, just let me know...
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
cross-project-issues-dev mailing list