Le 26 août 08 à 15:56, Xavier Hanin a écrit :
Hi,
I've been working on the remaining issues targetted to 2.0-RC1, and
only a
few are remaining.
We have:
IVY-835 <ivy:install> ant task downloads wrong jars from maven
repositories
IVY-675 Wrong graph of nodes is logged when circular dependency is
detected
IVY-349 Endless recursion in Report
=> those are about to be closed as cannot reproduce if no new
activity
happens soon
IVY-652 Ivy constructs incorrect URL if artifact path contains spaces
=> This one Maarten you seem to have already made good progress, any
insight on the remaining time?
IVY-387 Absolute and relative path
IVY-232 Incorrect directory path resolve when running from a
different
directory
=> These two are rather old, assigned to you Gilles. Any progress on
these? Do you need help?
IVY-872 Improve performance
=> This one is new and assigned to you Gilles. I don't think this
should
be a show stopper for 2.0, and can be postponed to 2.0.1 if it takes
too
long to implement
So I think we're pretty close to be able to enter in 2.0 release
candidates
cycles, to finally get 2.0 out! Do you see any other outstanding
issue which
should get in 2.0? Would you agree with a plan trying to get 2.0 RC1
out
before mid september? Then how do you see the release candidates
cycles
going on? I'd be in favour of trying to keep the cycles short (sg
like every
2 weeks), and if no outstanding bug is reported in a cycle, then we
release
2.0 final with the same source code as the last RC. What do you
think of
this plan?
fine for me !
I have just a little issue that I would like to be addressed before
the release. It is about the OSGi version number of the rc and final
version. Version numbers in the OSGi environment needs to be ordered
alphabetically. Currently the OSGi version of the Ivy bundle is
2.0.0.rc1_$TIMESTAMP. So for the final version, we will have issues to
find a name "upper" than that one. I think we should better take
2.0.0.candidate1_$TIMESTAMP (it is still upper than "beta") and then
for the final : 2.0.0.final_$TIMESTAMP.
Another point, this one non blocker for the release, but it will be
cool if you can also release Ivy into the IvyDE update site
simultaneously.
Ivy has been re-packaged for the update site with the last release of
IvyDE. It would be cool to have it updated to the update without
involving a release of IvyDE. So I think that the best way to process
is to move the update site build process from the IvyDE build system
to the site build system. So the process would be:
- build the release of Ivy
- copy the new jar to /svn/ant/ivy/site/ivyde/updatesite/plugins/ (the
entire updatesite will be in svn, jars and .md5)
- update manually the site.xml in site/ivyde/updatesite/ so it
references the new version
- ant generate-ivy-feature optimize-updatesite checksum-updatesite
sign-updatesite
- commit the regenerated stuff
After the release is voted:
- there would be a classic site deployment, as the site include the
main updatesite
- the updatesite mirrors can be updated in updating /www/www.apache.org/dist/ant/ivyde/updatesite
on people.apache.org
If no one object I will take care of setting up this, put proper
detailed doc about the process in the wiki.
Note that this process is not blocker against an Ivy release, we could
have some delay between releasing Ivy and having it published into the
updatesite. But I have no doubt that some users will quickly ask to
have it updated on the Eclipse side :)
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
