I squashed the commits and pushed the revised documentation to simplify the code changes.
To recap, I would like ivy.xml to be one central descriptor of all dependencies and all artifacts (including the distribution archives) that are produced and published by the project. The release process should use that single descriptor by applying a single tool (Ivy) in all steps that need to resolve the dependencies or publish the artifacts. The problem is that using a single descriptor for development, installation and release exposes redundancies and accrecion of diverse tools in the release process. I understand some discomfort caused by that, but I hope that we may continue the dialog. Gintas 2018-01-20 8:59 GMT+01:00 Gintautas Grigelionis <g.grigelio...@gmail.com>: > The PR is currently focused on fetch.xml, as discussed with Stefan; I did > not commit anything regarding signing yet except removing signatures as Ivy > artifacts from ivy.xml. > > I am looking at what the distribution target does; should the distribution > archives be included in ivy.xml, then there's a lot of unnecessary checksum > generation that can be removed. On the other hand, we need Ivy 2.5 for > making SHA512 on the fly, so it's kind of catch 22. From my perspective, it > makes more sense to look at Ivy's release process, simplify it and > eventually use the relevant bits for Ant. > > Could anybody check the documentation of tar/untar regarding compression > attributes? > > TIA, Gintas > > 2018-01-20 6:48 GMT+01:00 Jaikiran Pai <jai.forums2...@gmail.com>: > >> A bit late to the discussion. I just finished going through the release >> instructions. It's a lengthy process (understandably). Having been involved >> in releases of some internal projects, I do not see anything out the >> ordinary in these steps. >> >> Coming to the artifact signing step, which is what the core of this >> discussion seems to be (correct me if that's not the case, the PR has too >> many different commits for me to narrow it down), I personally don't have >> any issues using the gpg tool usage that's explained in the instructions. >> >> Overall, I don't have any specific changes/suggestions to add especially >> since the steps themselves are clear enough and this only just affects the >> people who do the releases. >> >> -Jaikiran >> >> >> >> On 28/12/17 10:02 PM, Stefan Bodewig wrote: >> >>> Hi >>> >>> over in https://github.com/apache/ant/pull/54 Gintas is proposing to >>> automate some of the steps needed to cut a release of Ant that so far >>> have been performed manually. He's also ripping out the maven Ant task >>> stuff from fetch.xml and replacing it with Ivy, but that seems to be a >>> separate issue, it is just that automation becomes easier once fetch is >>> based on Ivy. At least that's my understanding of the situation, please >>> correct me if I'm wrong, Gintas. >>> >>> For the last few releases I have been the release manager but this will >>> not always be the case so it won't be a good idea if I enforce my taste >>> here. In particular as I seem to be willing to suffer more than many >>> other people cutting releases - judging from the moaning about the >>> release process in Commons which involves far fewer steps than cutting a >>> release of Ant. >>> >>> I'd ask you to look through the Release Process description[1] and look >>> for things that can and should be automated - assuming we can find a >>> reliable solution. Personally I prefer to stay in control at every >>> single step but maybe my level of paranoia is just wrong here. >>> >>> Cheers >>> >>> Stefan >>> >>> [1] https://github.com/apache/ant/blob/master/ReleaseInstructions >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>> For additional commands, e-mail: dev-h...@ant.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> >
