You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/08/26 15:56:15 UTC
Ivy 2.0 RC1 planning
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?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Ivy 2.0 RC1 planning
Posted by Xavier Hanin <xa...@gmail.com>.
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/
Re: Ivy 2.0 RC1 planning
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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
AW: Ivy 2.0 RC1 planning
Posted by Ja...@rzf.fin-nrw.de.
> > 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.
Could that be documented somewhere?
As naming is important for releasing, maybe in the release instructions?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy 2.0 RC1 planning
Posted by Xavier Hanin <xa...@gmail.com>.
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.
>
> 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
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/
Re: Ivy 2.0 RC1 planning
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy 2.0 RC1 planning
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Aug 28, 2008 at 10:31 AM, Gilles Scokart <gs...@gmail.com> wrote:
> >
> > 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?
> >
>
> Both are actually the same now. The IVY-387 was an aggregation of
> different absolute and relative path issues. All have been solved
> except IVY-232 which was a bigger change. [1]
> I think Matt may already has a patch, he just need some help to test.
Great! I can help on this, either to implement or test. I'll post a comment
on the issue to get attention from Matt and see how to procede.
>
>
>
> > 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
> >
>
> Correct. Most performance issues that I have observed are now fixed.
> I just have one pending. I think that (at least on my benchmark
> project) there is still too much ivy file parsing. It seems that the
> number of ivy file parsing grows with the size of the repository (or
> with the size of the cache) which I didn't explain yet and is a source
> of poor performances.
> This is the last point that I plan to fix. After I will stop. As it
> is not a show stopper this can be postponed to 2.0.1 if it is not done
> for the RC-1. release.
Sounds like a good plan.
>
>
>
> > 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?
>
> +1.
>
> I also think that once the RC-1 is released, we should start the 2.0
> branch (or 2.0.0). Keeping the trunk for changes that will be for
> 2.0.1 (for example possibly the end of my IVY-872), and the branch
> only for 2.0-RC show stoppers.
+1
Xavier
>
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> 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/
Re: Ivy 2.0 RC1 planning
Posted by Gilles Scokart <gs...@gmail.com>.
>
> 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?
>
Both are actually the same now. The IVY-387 was an aggregation of
different absolute and relative path issues. All have been solved
except IVY-232 which was a bigger change. [1]
I think Matt may already has a patch, he just need some help to test.
> 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
>
Correct. Most performance issues that I have observed are now fixed.
I just have one pending. I think that (at least on my benchmark
project) there is still too much ivy file parsing. It seems that the
number of ivy file parsing grows with the size of the repository (or
with the size of the cache) which I didn't explain yet and is a source
of poor performances.
This is the last point that I plan to fix. After I will stop. As it
is not a show stopper this can be postponed to 2.0.1 if it is not done
for the RC-1. release.
> 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?
+1.
I also think that once the RC-1 is released, we should start the 2.0
branch (or 2.0.0). Keeping the trunk for changes that will be for
2.0.1 (for example possibly the end of my IVY-872), and the branch
only for 2.0-RC show stoppers.
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy 2.0 RC1 planning
Posted by Xavier Hanin <xa...@gmail.com>.
Hi,
It seems we're getting very close to be able to release 2.0-RC1. The current
issues targeted for 2.0-RC1 consist only of the performance issue that we
agreed to postpone, and an issue on which we wait for some additional input,
if none comes we can resolve it. Therefore current trunk should be very
close to what 2.0-RC1 will be.
So I suggest all Ivy developers and users following the trunk to build from
trunk now, and test this trunk version before we release 2.0-RC1. It's
always quicker to fix things before the release is done.
Then if we agree we could prepare the release for the vote before the end of
the week. I volunteer to be release manager for this version, unless someone
steps up.
Xavier
On Tue, Aug 26, 2008 at 3:56 PM, Xavier Hanin <xa...@gmail.com>wrote:
> 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?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Ivy 2.0 RC1 planning
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 26 Aug 2008, Xavier Hanin <xa...@gmail.com> wrote:
> 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.
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org