I have signed the tag: See https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0 <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0>
I’ve also build the updatesite ready to be published: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/ <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/> And I’ve pushed the jars to the Nexus staging repository: https://repository.apache.org/content/repositories/orgapacheant-1006/ So I think we’re good. For now we have one -1 and three +1 (including me). I’ll keep the vote open a couple of days, to be sure everyone had the time to vote. And I’ll promote the artifacts. Nicolas > Le 17 déc. 2014 à 14:25, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit > : > > >> Le 17 déc. 2014 à 04:09, Antoine Levy Lambert <anto...@gmx.de> a écrit : >> >> Nicolas, Jean-Louis, what are your thoughts ? >> >> The problem reported by Stefan with the ivy.xml in the source archive must >> be caused by something in the build process replacing the ivy.xml of the >> source tree with an expanded version of the same file generated when the >> <ivy:publish/> task runs ? > > The purpose of this change is that it fixes the dependencies of Ivy. I see no > particular harm here. > > But as Stefan, generally speaking, I prefer the source release to be an > extract of the source repository. So there is no possible confusion. > >> I guess a minor edit in the build file to make this modified version of >> ivy.xml go somewhere under the build folder should address this issue for >> this release and the next ones. >> >> I have not spent myself a lot of time on ivy yet but I would like to spend >> some in 2015 - or maybe even next week if my kids are busy out of the house … >> >> I also know how it feels when one creates a release candidate and some minor >> problems are found and one has to again go through 20 steps in a >> ReleaseInstructions document … > > Actually releasing Ivy is quite straight forward, no issues with that. > See: http://ant.apache.org/ivy/history/trunk/dev/makerelease.html > <http://ant.apache.org/ivy/history/trunk/dev/makerelease.html> > Probably the signing of the artifacts can be more automatic. I have seen > there is ant target for that but I haven’t tested it yet. > > What trouble me more is what is the exact process to push artifacts into > Maven repo after the release. And we’ll need to figure out how to push it > into the Eclipse updatesite too. > >> But I am sure we will get there finally. > > I am sure too. We have to either be patient or actively act on it, depending > on our available time. > >> On Dec 14, 2014, at 5:43 AM, Stefan Bodewig <bode...@apache.org> wrote: >> >>> We should be using signed tags (git tag -s or -u) rather than >>> lightweight tags for releases. I know we haven't cut any releases from >>> git so far, so we'll be learning as we go along. > > I do not know how it works, but I’ll figure it out. And update the release > documentation. > > Nicolas >
