ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: Ant Release Process
Date Fri, 12 Jan 2018 17:43:33 GMT
BTW, the trouble with Commons OpenPGP is that it's not developed and the
only version available is using an ancient BouncyCastle.

Gintas

2018-01-12 18:30 GMT+01:00 Gintautas Grigelionis <g.grigelionis@gmail.com>:

> I was looking at build files in Ivy project, and realised that Ivy was
> using Commons OpenPGP as well.
> It's still there in the build files, but it's not used in
> publishing/upload after signers were introduced;
> only for signing the distribution archives. The question, naturally, is
> whether it makes sense to add
> distributions to ivy.xml file as a separate conf and use a filesystem
> resolver to sign and compute
> checksums for them, too.
>
> Gintas
>
> 2017-12-28 18:38 GMT+01:00 Gintautas Grigelionis <g.grigelionis@gmail.com>
> :
>
>> Hello,
>>
>> I am proposing to rip off Maven Ant tasks (for reasons described in the
>> discussion to PR)
>> and Commons OpenPGP (correspondingly, fetch and signit for brevity). Ivy
>> can do all of that,
>> and it is already used by upload. The bonus is, using Ivy properly would
>> simplify project
>> setup in IDE and showcase Ivy.
>>
>> The fetch part raises questions of what the baseline should be. My
>> proposal is to use the
>> latest third party libraries available as allowed by the chosen JRE
>> (unless there are good
>> reasons to not doing that -- like 20+ dependencies in JRuby 1.7 or 9).
>>
>> The signit part is partly a question of automation (fetch touches upon
>> that, too; see step 3
>> in the release process) and partly of documenting the artifacts that are
>> part of a release.
>> Use of Ivy signer makes step 10 redundant and simplifies ivy.xml; I
>> suggested adding
>> distrib artifacts to ivy.xml and using a filesystem resolver with a
>> signer to copy the
>> artifacts to Subversion in step 17.
>>
>> Gintas
>>
>>
>> 2017-12-28 17:32 GMT+01:00 Stefan Bodewig <bodewig@apache.org>:
>>
>>> 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-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>
>

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