ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy 2.0 RC1 planning
Date Thu, 28 Aug 2008 15:48:19 GMT
On Thu, Aug 28, 2008 at 5:31 PM, Nicolas Lalevée <
> 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.

> 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/
> on
> 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


> Nicolas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message