On Thu, Aug 28, 2008 at 6:45 PM, Nicolas Lalevée <[EMAIL PROTECTED] > wrote:
> > Le 28 août 08 à 17:48, Xavier Hanin a écrit : > > > On Thu, Aug 28, 2008 at 5:31 PM, Nicolas Lalevée < >> [EMAIL PROTECTED] >> >>> wrote: >>> >> >> >>> 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. >>> >> >> Good point. Maybe for the OSGi bundle version we could use cr instead of >> rc: >> 2.0.0.cr1_$TIMESTAMP. Some projects use candidate release instead of >> release >> candidate, so this is pretty well accepted and understood. >> > > ok. It is fine for me too. > > > > >> >> >> >>> 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 :) >>> >> >> That sounds like a good plan, very useful for IvyDE users. About >> documenting >> the process, I'd prefer if this could go on the Ivy release documentation >> page: >> http://ant.apache.org/ivy/history/trunk/dev/makerelease.html >> > > I forgot about that page. > So I think I will create a page just next to it, and add a new step that > points to the new page in makerelease.html, as the update site release > process should also work when releasing IvyDE. Fine for me. Xavier > > > Nicolas > > > > >> >> Xavier >> >> >> >>> >>> Nicolas >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> Xavier Hanin - Independent Java Consultant >> http://xhab.blogspot.com/ >> http://ant.apache.org/ivy/ >> http://www.xoocode.org/ >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
