ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Ivy 2.0 RC1 planning
Date Thu, 28 Aug 2008 16:45:08 GMT

Le 28 août 08 à 17:48, Xavier Hanin a écrit :

> On Thu, Aug 28, 2008 at 5:31 PM, Nicolas Lalevée <nicolas.lalevee@hibnet.org
>> 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.

Nicolas


>
>
> Xavier
>
>
>>
>>
>> Nicolas
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> -- 
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message