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