ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Ivy 2.0 RC1 planning
Date Thu, 28 Aug 2008 16:52:20 GMT
On Thu, Aug 28, 2008 at 6:45 PM, Nicolas Lalevée <nicolas.lalevee@hibnet.org
> wrote:

>
> 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.

Fine for me.

Xavier


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


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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