Now that we have a little more experience with the maintenance of an
Eclipse updatesite, I see some points that needs improvements.
During the release of Ivy, there was a period when the updatesite is
somehow "released" with the new jars and waiting for the vote, but not
in svn, only on the release manager's machine. I think we should
improve that and do some release branches for the updatesite.
Another point that seems to me now just complicating the release
process for no real usefullness. The main Eclipse updatesite is there:
http://ant.apache.org/ivy/ivyde/updatesite, whereas the jars are
deployed on the "mirrors", on http://www.apache.org/dist/ant/ivyde/updatesite
. Actually there is no need to have the update site deployed on
ant.apache.org/ivy/ivyde. Everything can be handled on www.apache.org/dist/ant/ivyde/
. In fact we can already use http://www.apache.org/dist/ant/ivyde/updatesite
as the main updatesite of IvyDE. We can merge them, so the main
updatesite will also be the mirror one, this will simplify the
deployment of the updatesite. And from the end user point of view it
will just be another url.
So my proposal:
- deprecate now (but not disable it) http://ant.apache.org/ivy/ivyde/updatesite
and recommand to use http://ant.apache.org/ivy/ivyde/updatesite
- create http://svn.apache.org/repos/asf/ant/ivy/updatesite with a
trunk-branches-tags structure
- move the updatesite build system from the site build system to
that new updatesite "project", so the deprecated updatesite will be
manual partial copy of that new main one.
- update the release doc accordingly
And once we decide to disable the update site on ant.apache.org remove
the updatesite artifacts from the site, so it would be not accessible
anymore, and just keep the cgi script that compute the urls of the
apache mirrors.
WDYT ?
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
