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: dev-unsubscribe@(protected)
For additional commands, e-mail: dev-help@(protected)