You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <cc...@apache.org> on 2015/05/19 21:36:52 UTC
In shape for a 2.4.4 release?
Hi guys,
I wanted to check with you what is preventing us from releasing 2.4.4.
Apart from the usual bugfixes, I think the necessary work on the source
code itself to match the Apache guidance has been done (in particular
licenses checks).
>From my perspective it should be possible to release using the "old
process" with subtle differences:
- a release manager chosen from the IPMC will initiate the release
- release will be done from the CI server
- binaries/sources/distributions will be signed automatically, as usual,
through Bintray
- Maven artifacts will be published automatically on Artifactory (OJO)
So far, nothing differs from the usual process but:
- Maven Central synchronization *will* be disabled, instead of done
automatically until now, so that we can cancel the release if it is
downvoted
- Sources/distributions need to be copied manually from Bintray to [1] by
the release manager (attn mentors: how?)
- since we do not generate MD5 files through Gradle yet (it's not a
technical problem), the release manager should generate the checksums for
sources/distributions/binaries and upload them to [1] too. An open question
is whether those signatures should be generated in Bintray, in which case
we need support from them, or from our side, in which case we have to
update the build to generate them and make them artifacts.
- release manager announces on dev@ and voting starts
- if vote is positive, release manager asks IPMC to vote
- if vote is positive, release manager triggers Maven Central
synchronization from Bintray and announces the release on the MLs
- if vote is positive, website needs to be updated too [2]
We have chosen to use a version number *without* -incubating for the
artifacts. Only the sources zip will have -incubating in the file name, as
the incubator policy mandates. The website download logic will have to be
adapted for this special case.
What do you think?
[1] https://dist.apache.org/repos/dist/release/incubator/groovy
[2] https://github.com/groovy/groovy-website
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <cc...@apache.org>.
2015-05-19 21:59 GMT+02:00 Andrew Bayer <an...@gmail.com>:
> Source artifacts will need to be posted to dist.apache.org - that's the
> canonical location for all Apache releases.
>
Yup, if it wasn't clear, that was what I meant with "release manager has to
copy to [1]".
> We'll also need to make sure that http://creadur.apache.org/rat/ verifies
> that we don't have license issues, etc - looks like Samza has done some of
> the work for integrating Gradle and Rat already (
> https://github.com/apache/samza/blob/master/gradle/rat.gradle) so we may
> be able to build on that.
>
I have used a license plugin for Gradle to do it actually. But if someone
wants to run Rat before we start the release, I'd be happy to have the
result.
>
> A.
>
> On Tue, May 19, 2015 at 12:36 PM, Cédric Champeau <cc...@apache.org>
> wrote:
>
>> Hi guys,
>>
>> I wanted to check with you what is preventing us from releasing 2.4.4.
>> Apart from the usual bugfixes, I think the necessary work on the source
>> code itself to match the Apache guidance has been done (in particular
>> licenses checks).
>>
>> From my perspective it should be possible to release using the "old
>> process" with subtle differences:
>>
>> - a release manager chosen from the IPMC will initiate the release
>> - release will be done from the CI server
>> - binaries/sources/distributions will be signed automatically, as usual,
>> through Bintray
>> - Maven artifacts will be published automatically on Artifactory (OJO)
>>
>> So far, nothing differs from the usual process but:
>>
>> - Maven Central synchronization *will* be disabled, instead of done
>> automatically until now, so that we can cancel the release if it is
>> downvoted
>> - Sources/distributions need to be copied manually from Bintray to [1] by
>> the release manager (attn mentors: how?)
>> - since we do not generate MD5 files through Gradle yet (it's not a
>> technical problem), the release manager should generate the checksums for
>> sources/distributions/binaries and upload them to [1] too. An open question
>> is whether those signatures should be generated in Bintray, in which case
>> we need support from them, or from our side, in which case we have to
>> update the build to generate them and make them artifacts.
>> - release manager announces on dev@ and voting starts
>> - if vote is positive, release manager asks IPMC to vote
>> - if vote is positive, release manager triggers Maven Central
>> synchronization from Bintray and announces the release on the MLs
>> - if vote is positive, website needs to be updated too [2]
>>
>> We have chosen to use a version number *without* -incubating for the
>> artifacts. Only the sources zip will have -incubating in the file name, as
>> the incubator policy mandates. The website download logic will have to be
>> adapted for this special case.
>>
>> What do you think?
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/groovy
>> [2] https://github.com/groovy/groovy-website
>>
>>
>
Re: In shape for a 2.4.4 release?
Posted by Andrew Bayer <an...@gmail.com>.
Source artifacts will need to be posted to dist.apache.org - that's the
canonical location for all Apache releases. We'll also need to make sure
that http://creadur.apache.org/rat/ verifies that we don't have license
issues, etc - looks like Samza has done some of the work for integrating
Gradle and Rat already (
https://github.com/apache/samza/blob/master/gradle/rat.gradle) so we may be
able to build on that.
A.
On Tue, May 19, 2015 at 12:36 PM, Cédric Champeau <cc...@apache.org>
wrote:
> Hi guys,
>
> I wanted to check with you what is preventing us from releasing 2.4.4.
> Apart from the usual bugfixes, I think the necessary work on the source
> code itself to match the Apache guidance has been done (in particular
> licenses checks).
>
> From my perspective it should be possible to release using the "old
> process" with subtle differences:
>
> - a release manager chosen from the IPMC will initiate the release
> - release will be done from the CI server
> - binaries/sources/distributions will be signed automatically, as usual,
> through Bintray
> - Maven artifacts will be published automatically on Artifactory (OJO)
>
> So far, nothing differs from the usual process but:
>
> - Maven Central synchronization *will* be disabled, instead of done
> automatically until now, so that we can cancel the release if it is
> downvoted
> - Sources/distributions need to be copied manually from Bintray to [1] by
> the release manager (attn mentors: how?)
> - since we do not generate MD5 files through Gradle yet (it's not a
> technical problem), the release manager should generate the checksums for
> sources/distributions/binaries and upload them to [1] too. An open question
> is whether those signatures should be generated in Bintray, in which case
> we need support from them, or from our side, in which case we have to
> update the build to generate them and make them artifacts.
> - release manager announces on dev@ and voting starts
> - if vote is positive, release manager asks IPMC to vote
> - if vote is positive, release manager triggers Maven Central
> synchronization from Bintray and announces the release on the MLs
> - if vote is positive, website needs to be updated too [2]
>
> We have chosen to use a version number *without* -incubating for the
> artifacts. Only the sources zip will have -incubating in the file name, as
> the incubator policy mandates. The website download logic will have to be
> adapted for this special case.
>
> What do you think?
>
> [1] https://dist.apache.org/repos/dist/release/incubator/groovy
> [2] https://github.com/groovy/groovy-website
>
>
Re: In shape for a 2.4.4 release?
Posted by Paul King <pa...@asert.com.au>.
That sounds about right to me. It might also be nice if one of our mentors
can do a trial run check of the source dist zip for us. You can find snapshot
artifacts similar to what we would produce for the release on the CI server:
http://ci.groovy-lang.org/viewLog.html?buildId=23085&tab=artifacts&buildTypeId=Groovy_Jdk7Build
[build number will vary - you might need to traverse down from a higher
directory - click on "artifacts" on the "JDK 7 Build"]
There are some known things we have, e.g. a binary jar for testing purposes,
that we think are OK, but we need everyone on the same page wrt such things.
And we might need a little time to fix anything that we can't go forward with.
You can use "gradle(w) rat" to invoke rat with our current exclusions file.
The Rat integration needs some work. It currently uses the command-line
integration which is a little limited. We need some tweaks for proper
gradle integration at some point.
Cheers, Paul.
On 1/06/2015 5:55 AM, Pascal Schumacher wrote:
> So, left to do is just:
>
> - add the checksum generation for source zip to the gradle build (optional)
> - adjust the website to handle the "incubating" qualifiy of the source zip
> - find somebody who is willing to act as a release manger
>
> I'm I missing anything?
>
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Re: In shape for a 2.4.4 release?
Posted by Pascal Schumacher <pa...@gmx.net>.
Yes, please. It has been to long since the last release. :(
Thanks for volunteering. :)
Am 05.06.2015 um 22:00 schrieb Cédric Champeau:
> Thanks guys! I think we have everything required for a 2.4.4 release.
> What do you guys think of giving it a try? The first one is likely to
> cause some troubles anyway :) I volunteer as the release manager (and
> I think it's probably the best thing to do since I am tweaking the
> release process). WDYT?
>
> 2015-06-02 10:22 GMT+02:00 JBaruch <jbaruch@jfrog.com
> <ma...@jfrog.com>>:
>
> Done :)
>
> Please add md5=true to the releaseToBintray call.
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com <http://www.jfrog.com>
> +972544954353 <tel:%2B972544954353>
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> SwampUP <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jbaruch@jfrog.com
> <ma...@jfrog.com>> wrote:
>
> We'll add the note there once it's ready (which will be really
> soon).
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com <http://www.jfrog.com>
> +972544954353 <tel:%2B972544954353>
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> SwampUP <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau
> <cedric.champeau@gmail.com <ma...@gmail.com>>
> wrote:
>
> BTW would be nice if someone on your team could reply on
> the Apache thread. Actually it would be even better if
> someone wants to become a Groovy committer and be
> responsible for that integration :)
>
>
> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>> Thanks!
>>
>> 2015-06-01 10:52 GMT+02:00 JBaruch <jbaruch@jfrog.com
>> <ma...@jfrog.com>>:
>>
>> We are on it. Will update ASAP.
>>
>> Baruch.
>>
>> --
>> JFrog Developer Advocate
>> www.jfrog.com <http://www.jfrog.com>
>> +972544954353 <tel:%2B972544954353>
>> @jbaruch <https://twitter.com/jbaruch/>
>> http://linkd.in/jbaruch
>>
>> SwampUP <http://bit.ly/1Egh5Iw>
>>
>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge
>> <glaforge@gmail.com <ma...@gmail.com>> wrote:
>>
>> Ping JFrog :-)
>>
>> ---------- Forwarded message ----------
>> From: *Cédric Champeau*
>> <cedric.champeau@gmail.com
>> <ma...@gmail.com>>
>> Date: 2015-06-01 9:52 GMT+02:00
>> Subject: Re: In shape for a 2.4.4 release?
>> To: dev@groovy.incubator.apache.org
>> <ma...@groovy.incubator.apache.org>
>>
>>
>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>
>> So, left to do is just:
>>
>> - add the checksum generation for source zip
>> to the gradle build (optional)
>>
>> Apparently we already have those MD5 files when
>> uploading everything to artifactory and bintray.
>> It's just that they are not visible, so I am
>> waiting for an answer from JFrog about what we
>> can do.
>>
>> - adjust the website to handle the
>> "incubating" qualifiy of the source zip
>> - find somebody who is willing to act as a
>> release manger
>>
>> I'm I missing anything?
>>
>>
>>
>> --
>> Cédric Champeau
>> Groovy language developer
>> http://twitter.com/CedricChampeau
>> http://melix.github.io/blog
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Product Ninja & Advocate at Restlet
>> <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> /
>> Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
> --
> Cédric Champeau
> Groovy language developer
> http://twitter.com/CedricChampeau
> http://melix.github.io/blog
>
>
>
>
Re: In shape for a 2.4.4 release?
Posted by Paul King <pa...@asert.com.au>.
+1, happy to help if I can.
On 6/06/2015 6:00 AM, Cédric Champeau wrote:
> Thanks guys! I think we have everything required for a 2.4.4 release. What do you guys think of giving it a try? The first one is likely to cause some troubles anyway :) I volunteer as the release manager (and I think it's probably the best thing to do since I am tweaking the release process). WDYT?
>
> 2015-06-02 10:22 GMT+02:00 JBaruch <jbaruch@jfrog.com <ma...@jfrog.com>>:
>
> Done :)
>
> Please add md5=true to the releaseToBintray call.
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com <http://www.jfrog.com>
> +972544954353 <tel:%2B972544954353>
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> SwampUP <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jbaruch@jfrog.com <ma...@jfrog.com>> wrote:
>
> We'll add the note there once it's ready (which will be really soon).
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com <http://www.jfrog.com>
> +972544954353 <tel:%2B972544954353>
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> SwampUP <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau <cedric.champeau@gmail.com <ma...@gmail.com>> wrote:
>
> BTW would be nice if someone on your team could reply on the Apache thread. Actually it would be even better if someone wants to become a Groovy committer and be responsible for that integration :)
>
>
> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>> Thanks!
>>
>> 2015-06-01 10:52 GMT+02:00 JBaruch <jbaruch@jfrog.com <ma...@jfrog.com>>:
>>
>> We are on it. Will update ASAP.
>>
>> Baruch.
>>
>> --
>> JFrog Developer Advocate
>> www.jfrog.com <http://www.jfrog.com>
>> +972544954353 <tel:%2B972544954353>
>> @jbaruch <https://twitter.com/jbaruch/>
>> http://linkd.in/jbaruch
>>
>> SwampUP <http://bit.ly/1Egh5Iw>
>>
>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge <glaforge@gmail.com <ma...@gmail.com>> wrote:
>>
>> Ping JFrog :-)
>>
>> ---------- Forwarded message ----------
>> From: *Cédric Champeau* <cedric.champeau@gmail.com <ma...@gmail.com>>
>> Date: 2015-06-01 9:52 GMT+02:00
>> Subject: Re: In shape for a 2.4.4 release?
>> To: dev@groovy.incubator.apache.org <ma...@groovy.incubator.apache.org>
>>
>>
>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>
>> So, left to do is just:
>>
>> - add the checksum generation for source zip to the gradle build (optional)
>>
>> Apparently we already have those MD5 files when uploading everything to artifactory and bintray. It's just that they are not visible, so I am waiting for an answer from JFrog about what we can do.
>>
>> - adjust the website to handle the "incubating" qualifiy of the source zip
>> - find somebody who is willing to act as a release manger
>>
>> I'm I missing anything?
>>
>>
>>
>> --
>> Cédric Champeau
>> Groovy language developer
>> http://twitter.com/CedricChampeau
>> http://melix.github.io/blog
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
> --
> Cédric Champeau
> Groovy language developer
> http://twitter.com/CedricChampeau
> http://melix.github.io/blog
>
>
>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <cc...@apache.org>.
Not sure, when I have some time :) I still have to make a checklist :)
2015-06-05 22:02 GMT+02:00 Guillaume Laforge <gl...@gmail.com>:
> Woohooo, is all I can say :-)
> When do you want to launch that release?
>
> 2015-06-05 22:00 GMT+02:00 Cédric Champeau <cc...@apache.org>:
>
>> Thanks guys! I think we have everything required for a 2.4.4 release.
>> What do you guys think of giving it a try? The first one is likely to cause
>> some troubles anyway :) I volunteer as the release manager (and I think
>> it's probably the best thing to do since I am tweaking the release
>> process). WDYT?
>>
>> 2015-06-02 10:22 GMT+02:00 JBaruch <jb...@jfrog.com>:
>>
>>> Done :)
>>>
>>> Please add md5=true to the releaseToBintray call.
>>>
>>> Baruch.
>>>
>>> --
>>> JFrog Developer Advocate
>>> www.jfrog.com
>>> +972544954353
>>> @jbaruch <https://twitter.com/jbaruch/>
>>> http://linkd.in/jbaruch
>>>
>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>
>>> On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jb...@jfrog.com> wrote:
>>>
>>>> We'll add the note there once it's ready (which will be really soon).
>>>>
>>>> Baruch.
>>>>
>>>> --
>>>> JFrog Developer Advocate
>>>> www.jfrog.com
>>>> +972544954353
>>>> @jbaruch <https://twitter.com/jbaruch/>
>>>> http://linkd.in/jbaruch
>>>>
>>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>>
>>>> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau <
>>>> cedric.champeau@gmail.com> wrote:
>>>>
>>>>> BTW would be nice if someone on your team could reply on the Apache
>>>>> thread. Actually it would be even better if someone wants to become a
>>>>> Groovy committer and be responsible for that integration :)
>>>>>
>>>>>
>>>>> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>>>>>
>>>>> Thanks!
>>>>>
>>>>> 2015-06-01 10:52 GMT+02:00 JBaruch <jb...@jfrog.com>:
>>>>>
>>>>>> We are on it. Will update ASAP.
>>>>>>
>>>>>> Baruch.
>>>>>>
>>>>>> --
>>>>>> JFrog Developer Advocate
>>>>>> www.jfrog.com
>>>>>> +972544954353
>>>>>> @jbaruch <https://twitter.com/jbaruch/>
>>>>>> http://linkd.in/jbaruch
>>>>>>
>>>>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>>>>
>>>>>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge <
>>>>>> glaforge@gmail.com> wrote:
>>>>>>
>>>>>>> Ping JFrog :-)
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Cédric Champeau <ce...@gmail.com>
>>>>>>> Date: 2015-06-01 9:52 GMT+02:00
>>>>>>> Subject: Re: In shape for a 2.4.4 release?
>>>>>>> To: dev@groovy.incubator.apache.org
>>>>>>>
>>>>>>>
>>>>>>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>>>>>>
>>>>>>>> So, left to do is just:
>>>>>>>>
>>>>>>>> - add the checksum generation for source zip to the gradle build
>>>>>>>> (optional)
>>>>>>>>
>>>>>>> Apparently we already have those MD5 files when uploading
>>>>>>> everything to artifactory and bintray. It's just that they are not visible,
>>>>>>> so I am waiting for an answer from JFrog about what we can do.
>>>>>>>
>>>>>>> - adjust the website to handle the "incubating" qualifiy of the
>>>>>>>> source zip
>>>>>>>> - find somebody who is willing to act as a release manger
>>>>>>>>
>>>>>>>> I'm I missing anything?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cédric Champeau
>>>>>>> Groovy language developer
>>>>>>> http://twitter.com/CedricChampeau
>>>>>>> http://melix.github.io/blog
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Guillaume Laforge
>>>>>>> Groovy Project Manager
>>>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>>>
>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Guillaume Laforge
>>>>> Groovy Project Manager
>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>
>>>>> Blog: http://glaforge.appspot.com/
>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cédric Champeau
>>>>> Groovy language developerhttp://twitter.com/CedricChampeauhttp://melix.github.io/blog
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: In shape for a 2.4.4 release?
Posted by Guillaume Laforge <gl...@gmail.com>.
Woohooo, is all I can say :-)
When do you want to launch that release?
2015-06-05 22:00 GMT+02:00 Cédric Champeau <cc...@apache.org>:
> Thanks guys! I think we have everything required for a 2.4.4 release. What
> do you guys think of giving it a try? The first one is likely to cause some
> troubles anyway :) I volunteer as the release manager (and I think it's
> probably the best thing to do since I am tweaking the release process).
> WDYT?
>
> 2015-06-02 10:22 GMT+02:00 JBaruch <jb...@jfrog.com>:
>
>> Done :)
>>
>> Please add md5=true to the releaseToBintray call.
>>
>> Baruch.
>>
>> --
>> JFrog Developer Advocate
>> www.jfrog.com
>> +972544954353
>> @jbaruch <https://twitter.com/jbaruch/>
>> http://linkd.in/jbaruch
>>
>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>
>> On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jb...@jfrog.com> wrote:
>>
>>> We'll add the note there once it's ready (which will be really soon).
>>>
>>> Baruch.
>>>
>>> --
>>> JFrog Developer Advocate
>>> www.jfrog.com
>>> +972544954353
>>> @jbaruch <https://twitter.com/jbaruch/>
>>> http://linkd.in/jbaruch
>>>
>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>
>>> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau <
>>> cedric.champeau@gmail.com> wrote:
>>>
>>>> BTW would be nice if someone on your team could reply on the Apache
>>>> thread. Actually it would be even better if someone wants to become a
>>>> Groovy committer and be responsible for that integration :)
>>>>
>>>>
>>>> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>>>>
>>>> Thanks!
>>>>
>>>> 2015-06-01 10:52 GMT+02:00 JBaruch <jb...@jfrog.com>:
>>>>
>>>>> We are on it. Will update ASAP.
>>>>>
>>>>> Baruch.
>>>>>
>>>>> --
>>>>> JFrog Developer Advocate
>>>>> www.jfrog.com
>>>>> +972544954353
>>>>> @jbaruch <https://twitter.com/jbaruch/>
>>>>> http://linkd.in/jbaruch
>>>>>
>>>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>>>
>>>>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge <glaforge@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Ping JFrog :-)
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Cédric Champeau <ce...@gmail.com>
>>>>>> Date: 2015-06-01 9:52 GMT+02:00
>>>>>> Subject: Re: In shape for a 2.4.4 release?
>>>>>> To: dev@groovy.incubator.apache.org
>>>>>>
>>>>>>
>>>>>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>>>>>
>>>>>>> So, left to do is just:
>>>>>>>
>>>>>>> - add the checksum generation for source zip to the gradle build
>>>>>>> (optional)
>>>>>>>
>>>>>> Apparently we already have those MD5 files when uploading everything
>>>>>> to artifactory and bintray. It's just that they are not visible, so I am
>>>>>> waiting for an answer from JFrog about what we can do.
>>>>>>
>>>>>> - adjust the website to handle the "incubating" qualifiy of the
>>>>>>> source zip
>>>>>>> - find somebody who is willing to act as a release manger
>>>>>>>
>>>>>>> I'm I missing anything?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cédric Champeau
>>>>>> Groovy language developer
>>>>>> http://twitter.com/CedricChampeau
>>>>>> http://melix.github.io/blog
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Guillaume Laforge
>>>>>> Groovy Project Manager
>>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>>
>>>>>> Blog: http://glaforge.appspot.com/
>>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Guillaume Laforge
>>>> Groovy Project Manager
>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>
>>>> Blog: http://glaforge.appspot.com/
>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>
>>>>
>>>>
>>>> --
>>>> Cédric Champeau
>>>> Groovy language developerhttp://twitter.com/CedricChampeauhttp://melix.github.io/blog
>>>>
>>>>
>>>
>>
>
--
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <ce...@gmail.com>.
Only the source zip will have the incubating classifier. Other artifacts
will be unchanged. I wonder if we should start using apache-groovy as the
base name for zip artifacts (not maven artifacts which must stay unchanged
to avoid horrible dependency management issues).
Le 6 juin 2015 10:28, "Russel Winder" <ru...@winder.org.uk> a écrit :
> On Fri, 2015-06-05 at 22:00 +0200, Cédric Champeau wrote:
> > Thanks guys! I think we have everything required for a 2.4.4 release.
> > What
> > do you guys think of giving it a try? The first one is likely to
> > cause some
> > troubles anyway :) I volunteer as the release manager (and I think
> > it's
> > probably the best thing to do since I am tweaking the release
> > process).
> > WDYT?
>
> Seems like a good idea to me.
>
> Almost certainly wise to write up all stages so as to begin a "release
> manager manual in the new Apache context".
>
> Do I recollect correctly that we have to put horrible classifiers on
> the artefacts because of the project state within Apache Foundation.
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <ce...@gmail.com>.
@Russel: I have started documenting the process here:
http://groovy-lang.org/wiki/incubation-release-process.html
I will complete the document as the release process continues. FYI, source
of the doc is here:
https://github.com/groovy/groovy-website/blob/master/site/src/site/wiki/incubation-release-process.adoc
2015-06-06 10:27 GMT+02:00 Russel Winder <ru...@winder.org.uk>:
> On Fri, 2015-06-05 at 22:00 +0200 Cédric Champeau wrote:
> > Thanks guys! I think we have everything required for a 2.4.4 release.
> > What
> > do you guys think of giving it a try? The first one is likely to
> > cause some
> > troubles anyway :) I volunteer as the release manager (and I think
> > it's
> > probably the best thing to do since I am tweaking the release
> > process).
> > WDYT?
>
> Seems like a good idea to me.
>
> Almost certainly wise to write up all stages so as to begin a "release
> manager manual in the new Apache context".
>
> Do I recollect correctly that we have to put horrible classifiers on
> the artefacts because of the project state within Apache Foundation.
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
Re: In shape for a 2.4.4 release?
Posted by Russel Winder <ru...@winder.org.uk>.
On Fri, 2015-06-05 at 22:00 +0200, Cédric Champeau wrote:
> Thanks guys! I think we have everything required for a 2.4.4 release.
> What
> do you guys think of giving it a try? The first one is likely to
> cause some
> troubles anyway :) I volunteer as the release manager (and I think
> it's
> probably the best thing to do since I am tweaking the release
> process).
> WDYT?
Seems like a good idea to me.
Almost certainly wise to write up all stages so as to begin a "release
manager manual in the new Apache context".
Do I recollect correctly that we have to put horrible classifiers on
the artefacts because of the project state within Apache Foundation.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <cc...@apache.org>.
Thanks guys! I think we have everything required for a 2.4.4 release. What
do you guys think of giving it a try? The first one is likely to cause some
troubles anyway :) I volunteer as the release manager (and I think it's
probably the best thing to do since I am tweaking the release process).
WDYT?
2015-06-02 10:22 GMT+02:00 JBaruch <jb...@jfrog.com>:
> Done :)
>
> Please add md5=true to the releaseToBintray call.
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com
> +972544954353
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jb...@jfrog.com> wrote:
>
>> We'll add the note there once it's ready (which will be really soon).
>>
>> Baruch.
>>
>> --
>> JFrog Developer Advocate
>> www.jfrog.com
>> +972544954353
>> @jbaruch <https://twitter.com/jbaruch/>
>> http://linkd.in/jbaruch
>>
>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>
>> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau <
>> cedric.champeau@gmail.com> wrote:
>>
>>> BTW would be nice if someone on your team could reply on the Apache
>>> thread. Actually it would be even better if someone wants to become a
>>> Groovy committer and be responsible for that integration :)
>>>
>>>
>>> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>>>
>>> Thanks!
>>>
>>> 2015-06-01 10:52 GMT+02:00 JBaruch <jb...@jfrog.com>:
>>>
>>>> We are on it. Will update ASAP.
>>>>
>>>> Baruch.
>>>>
>>>> --
>>>> JFrog Developer Advocate
>>>> www.jfrog.com
>>>> +972544954353
>>>> @jbaruch <https://twitter.com/jbaruch/>
>>>> http://linkd.in/jbaruch
>>>>
>>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>>
>>>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge <gl...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ping JFrog :-)
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Cédric Champeau <ce...@gmail.com>
>>>>> Date: 2015-06-01 9:52 GMT+02:00
>>>>> Subject: Re: In shape for a 2.4.4 release?
>>>>> To: dev@groovy.incubator.apache.org
>>>>>
>>>>>
>>>>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>>>>
>>>>>> So, left to do is just:
>>>>>>
>>>>>> - add the checksum generation for source zip to the gradle build
>>>>>> (optional)
>>>>>>
>>>>> Apparently we already have those MD5 files when uploading everything
>>>>> to artifactory and bintray. It's just that they are not visible, so I am
>>>>> waiting for an answer from JFrog about what we can do.
>>>>>
>>>>> - adjust the website to handle the "incubating" qualifiy of the
>>>>>> source zip
>>>>>> - find somebody who is willing to act as a release manger
>>>>>>
>>>>>> I'm I missing anything?
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cédric Champeau
>>>>> Groovy language developer
>>>>> http://twitter.com/CedricChampeau
>>>>> http://melix.github.io/blog
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Guillaume Laforge
>>>>> Groovy Project Manager
>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>
>>>>> Blog: http://glaforge.appspot.com/
>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>>
>>>
>>> --
>>> Cédric Champeau
>>> Groovy language developerhttp://twitter.com/CedricChampeauhttp://melix.github.io/blog
>>>
>>>
>>
>
Re: In shape for a 2.4.4 release?
Posted by JBaruch <jb...@jfrog.com>.
Done :)
Please add md5=true to the releaseToBintray call.
Baruch.
--
JFrog Developer Advocate
www.jfrog.com
+972544954353
@jbaruch <https://twitter.com/jbaruch/>
http://linkd.in/jbaruch
[image: SwampUP] <http://bit.ly/1Egh5Iw>
On Mon, Jun 1, 2015 at 11:59 AM, JBaruch <jb...@jfrog.com> wrote:
> We'll add the note there once it's ready (which will be really soon).
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com
> +972544954353
> @jbaruch <https://twitter.com/jbaruch/>
> http://linkd.in/jbaruch
>
> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>
> On Mon, Jun 1, 2015 at 11:56 AM, Cédric Champeau <
> cedric.champeau@gmail.com> wrote:
>
>> BTW would be nice if someone on your team could reply on the Apache
>> thread. Actually it would be even better if someone wants to become a
>> Groovy committer and be responsible for that integration :)
>>
>>
>> On 06/01/2015 10:54 AM, Guillaume Laforge wrote:
>>
>> Thanks!
>>
>> 2015-06-01 10:52 GMT+02:00 JBaruch <jb...@jfrog.com>:
>>
>>> We are on it. Will update ASAP.
>>>
>>> Baruch.
>>>
>>> --
>>> JFrog Developer Advocate
>>> www.jfrog.com
>>> +972544954353
>>> @jbaruch <https://twitter.com/jbaruch/>
>>> http://linkd.in/jbaruch
>>>
>>> [image: SwampUP] <http://bit.ly/1Egh5Iw>
>>>
>>> On Mon, Jun 1, 2015 at 10:55 AM, Guillaume Laforge <gl...@gmail.com>
>>> wrote:
>>>
>>>> Ping JFrog :-)
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Cédric Champeau <ce...@gmail.com>
>>>> Date: 2015-06-01 9:52 GMT+02:00
>>>> Subject: Re: In shape for a 2.4.4 release?
>>>> To: dev@groovy.incubator.apache.org
>>>>
>>>>
>>>> On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
>>>>
>>>>> So, left to do is just:
>>>>>
>>>>> - add the checksum generation for source zip to the gradle build
>>>>> (optional)
>>>>>
>>>> Apparently we already have those MD5 files when uploading everything
>>>> to artifactory and bintray. It's just that they are not visible, so I am
>>>> waiting for an answer from JFrog about what we can do.
>>>>
>>>> - adjust the website to handle the "incubating" qualifiy of the source
>>>>> zip
>>>>> - find somebody who is willing to act as a release manger
>>>>>
>>>>> I'm I missing anything?
>>>>>
>>>>
>>>>
>>>> --
>>>> Cédric Champeau
>>>> Groovy language developer
>>>> http://twitter.com/CedricChampeau
>>>> http://melix.github.io/blog
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Guillaume Laforge
>>>> Groovy Project Manager
>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>
>>>> Blog: http://glaforge.appspot.com/
>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>>
>>
>> --
>> Cédric Champeau
>> Groovy language developerhttp://twitter.com/CedricChampeauhttp://melix.github.io/blog
>>
>>
>
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <ce...@gmail.com>.
On 05/31/2015 09:55 PM, Pascal Schumacher wrote:
> So, left to do is just:
>
> - add the checksum generation for source zip to the gradle build
> (optional)
Apparently we already have those MD5 files when uploading everything to
artifactory and bintray. It's just that they are not visible, so I am
waiting for an answer from JFrog about what we can do.
> - adjust the website to handle the "incubating" qualifiy of the source
> zip
> - find somebody who is willing to act as a release manger
>
> I'm I missing anything?
--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
Re: In shape for a 2.4.4 release?
Posted by Pascal Schumacher <pa...@gmx.net>.
So, left to do is just:
- add the checksum generation for source zip to the gradle build (optional)
- adjust the website to handle the "incubating" qualifiy of the source zip
- find somebody who is willing to act as a release manger
I'm I missing anything?
Re: In shape for a 2.4.4 release?
Posted by Paul King <pa...@asert.com.au>.
On 21/05/2015 1:48 PM, Emmanuel Lécharny wrote:
> Le 21/05/15 00:21, Paul King a écrit :
>> On 20/05/2015 5:36 AM, Cédric Champeau wrote:
>>> I wanted to check with you what is preventing us from releasing
>>> 2.4.4. [...]
>>
>> I have a question for our mentors around licensing. Just a point of
>> clarification
>> for the official source distribution zip. We have a number of
>> dependencies
>> which our build brings in and we have incorporated the appropriate
>> license
>> information from those dependencies into our LICENSE and NOTICE files.
>> I believe this is exactly appropriate for the binary artifacts (jars) our
>> build produces and for the convenience binaries we will make available
>> (since
>> those artifacts contain software in binary form from the respective
>> dependency
>> projects). This complies with the wording in those licenses similar to:
>>
>> "... Redistribution and use in source and binary forms ... are permitted
>> provided that the following conditions are met:
>> * Redistributions of source code must retain the [various license
>> information]
>> * Redistributions in binary form must retain the [various license
>> information]"
>>
>> In our case it is the binary form that is relevant. All good so far.
>>
>> The point of clarification is about the source distribution zip itself.
>> Take ASM or ANTLR as an example. There is no source or binary artifacts
>> from those projects anywhere in our source zip. The build brings down the
>> needed binaries at build time which we subsequently bundle into our
>> produced binary artifacts. So, back to the wording above, there is
>> definitely no "redistribution" of source or binary but the fact that our
>> build goes on to incorporate said dependencies, does that count as "use"?
>>
>> So, should the ASM/ANTLR etc. license info appear in the LICENSE/NOTICE
>> files in the root of our source distribution zip? We currently do include
>> them but I am conscious of the need to keep those files containing just
>> the required information and no more.
>
> AFAIK, antlr produces Java code that requires a antlr bundle to run : in
> this case, you 'use' antlr.
>
> In other words, if the tool you use generates some Java code (or
> anything else) that is not using any part of the tool, then I don't
> think you need to retain the license.
OK, thanks for the clarification. I think what we have is correct then.
The Groovy parser requires Antlr and ASM to run, so we'll keep the licensing
in the source bundle. Always good just to double check.
Thanks, Paul.
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Re: In shape for a 2.4.4 release?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, May 20, 2015 at 8:48 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 21/05/15 00:21, Paul King a écrit :
>> On 20/05/2015 5:36 AM, Cédric Champeau wrote:
>>> I wanted to check with you what is preventing us from releasing
>>> 2.4.4. [...]
>>
>> I have a question for our mentors around licensing. Just a point of
>> clarification
>> for the official source distribution zip. We have a number of
>> dependencies
>> which our build brings in and we have incorporated the appropriate
>> license
>> information from those dependencies into our LICENSE and NOTICE files.
>> I believe this is exactly appropriate for the binary artifacts (jars) our
>> build produces and for the convenience binaries we will make available
>> (since
>> those artifacts contain software in binary form from the respective
>> dependency
>> projects). This complies with the wording in those licenses similar to:
>>
>> "... Redistribution and use in source and binary forms ... are permitted
>> provided that the following conditions are met:
>> * Redistributions of source code must retain the [various license
>> information]
>> * Redistributions in binary form must retain the [various license
>> information]"
>>
>> In our case it is the binary form that is relevant. All good so far.
>>
>> The point of clarification is about the source distribution zip itself.
>> Take ASM or ANTLR as an example. There is no source or binary artifacts
>> from those projects anywhere in our source zip. The build brings down the
>> needed binaries at build time which we subsequently bundle into our
>> produced binary artifacts. So, back to the wording above, there is
>> definitely no "redistribution" of source or binary but the fact that our
>> build goes on to incorporate said dependencies, does that count as "use"?
>>
>> So, should the ASM/ANTLR etc. license info appear in the LICENSE/NOTICE
>> files in the root of our source distribution zip? We currently do include
>> them but I am conscious of the need to keep those files containing just
>> the required information and no more.
>
> AFAIK, antlr produces Java code that requires a antlr bundle to run : in
> this case, you 'use' antlr.
>
> In other words, if the tool you use generates some Java code (or
> anything else) that is not using any part of the tool, then I don't
> think you need to retain the license.
This is exactly my understanding as well and something I've seen
on all the other projects I've participated.
Thanks,
Roman.
Re: In shape for a 2.4.4 release?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 21/05/15 00:21, Paul King a écrit :
> On 20/05/2015 5:36 AM, Cédric Champeau wrote:
>> I wanted to check with you what is preventing us from releasing
>> 2.4.4. [...]
>
> I have a question for our mentors around licensing. Just a point of
> clarification
> for the official source distribution zip. We have a number of
> dependencies
> which our build brings in and we have incorporated the appropriate
> license
> information from those dependencies into our LICENSE and NOTICE files.
> I believe this is exactly appropriate for the binary artifacts (jars) our
> build produces and for the convenience binaries we will make available
> (since
> those artifacts contain software in binary form from the respective
> dependency
> projects). This complies with the wording in those licenses similar to:
>
> "... Redistribution and use in source and binary forms ... are permitted
> provided that the following conditions are met:
> * Redistributions of source code must retain the [various license
> information]
> * Redistributions in binary form must retain the [various license
> information]"
>
> In our case it is the binary form that is relevant. All good so far.
>
> The point of clarification is about the source distribution zip itself.
> Take ASM or ANTLR as an example. There is no source or binary artifacts
> from those projects anywhere in our source zip. The build brings down the
> needed binaries at build time which we subsequently bundle into our
> produced binary artifacts. So, back to the wording above, there is
> definitely no "redistribution" of source or binary but the fact that our
> build goes on to incorporate said dependencies, does that count as "use"?
>
> So, should the ASM/ANTLR etc. license info appear in the LICENSE/NOTICE
> files in the root of our source distribution zip? We currently do include
> them but I am conscious of the need to keep those files containing just
> the required information and no more.
AFAIK, antlr produces Java code that requires a antlr bundle to run : in
this case, you 'use' antlr.
In other words, if the tool you use generates some Java code (or
anything else) that is not using any part of the tool, then I don't
think you need to retain the license.
Re: In shape for a 2.4.4 release?
Posted by Paul King <pa...@asert.com.au>.
On 20/05/2015 5:36 AM, Cédric Champeau wrote:
> I wanted to check with you what is preventing us from releasing 2.4.4. [...]
I have a question for our mentors around licensing. Just a point of clarification
for the official source distribution zip. We have a number of dependencies
which our build brings in and we have incorporated the appropriate license
information from those dependencies into our LICENSE and NOTICE files.
I believe this is exactly appropriate for the binary artifacts (jars) our
build produces and for the convenience binaries we will make available (since
those artifacts contain software in binary form from the respective dependency
projects). This complies with the wording in those licenses similar to:
"... Redistribution and use in source and binary forms ... are permitted
provided that the following conditions are met:
* Redistributions of source code must retain the [various license information]
* Redistributions in binary form must retain the [various license information]"
In our case it is the binary form that is relevant. All good so far.
The point of clarification is about the source distribution zip itself.
Take ASM or ANTLR as an example. There is no source or binary artifacts
from those projects anywhere in our source zip. The build brings down the
needed binaries at build time which we subsequently bundle into our
produced binary artifacts. So, back to the wording above, there is
definitely no "redistribution" of source or binary but the fact that our
build goes on to incorporate said dependencies, does that count as "use"?
So, should the ASM/ANTLR etc. license info appear in the LICENSE/NOTICE
files in the root of our source distribution zip? We currently do include
them but I am conscious of the need to keep those files containing just
the required information and no more.
Thanks, Paul.
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <ce...@gmail.com>.
2015-05-20 17:50 GMT+02:00 Andrew Bayer <an...@gmail.com>:
> Yeah, any commit needs to be done by an actual committer. What I'd advise
> for this release is that we do the TeamCity release build against a
> personal fork of the repo, where TeamCity has creds to push etc, and then
> the release manager pushes the commits/branches/tags to the canonical repo
> manually. It's a little awkward, but meets the requirements for ASF
> policies.
I see, this is probably the best thing to do at least for the first
release.
>
> Can I get access to the TeamCity setup and a walk through of the process?
>
For TeamCity I will send you an email with credentials. Release process is
described here [1] and here [2]. For [1] we should probably backup this
because it is going to be shutdown anytime soon. We can back it up through
a PR to [3].
> I'd like to start working on how I can (wearing my Infra hat here) figure
> out how to make this process smoother and better integrated with Apache
> processes going forward - and admittedly, how I can port it to Jenkins,
> given my personal biases. =) I am also interested in seeing how the Groovy
> release process may be able to provide a model for other ASF projects
> looking for a more automated release build process.
>
> A.
>
>
[1] http://docs.codehaus.org/display/GROOVY/Release+Process
[2] http://groovy-lang.org/wiki/groovy-release.html
[3] https://github.com/groovy/groovy-website/tree/master/site/src/site/wiki
Re: In shape for a 2.4.4 release?
Posted by Andrew Bayer <an...@gmail.com>.
Yeah, any commit needs to be done by an actual committer. What I'd advise
for this release is that we do the TeamCity release build against a
personal fork of the repo, where TeamCity has creds to push etc, and then
the release manager pushes the commits/branches/tags to the canonical repo
manually. It's a little awkward, but meets the requirements for ASF
policies.
Can I get access to the TeamCity setup and a walk through of the process?
I'd like to start working on how I can (wearing my Infra hat here) figure
out how to make this process smoother and better integrated with Apache
processes going forward - and admittedly, how I can port it to Jenkins,
given my personal biases. =) I am also interested in seeing how the Groovy
release process may be able to provide a model for other ASF projects
looking for a more automated release build process.
A.
On Wednesday, May 20, 2015, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 20/05/15 11:26, Cédric Champeau a écrit :
> > Another issue I remembered this morning: the artifactory plugin for
> > TeamCity that we use is responsible for creating a release branch and
> > tagging. It is also the one that updates the repository and changes the
> > version numbers automatically. It is going to be a problem because to do
> > this it requires credentials on the Git repo. Is this something that we
> can
> > ask to infra? Currently we use an authentication key, but user/password
> is
> > also supported. Of course we could cheat and use our personal
> credentials,
> > but ehm, if we can avoid this...
>
> If it's for a technical commit, then I think the best - and easier -
> would be to ask INFRA. If they don't want to create this special user,
> then the simplest solution would be to use the Release Manager creds,
> but I agree, that would be not really convenient.
>
>
>
Re: In shape for a 2.4.4 release?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/05/15 11:26, Cédric Champeau a écrit :
> Another issue I remembered this morning: the artifactory plugin for
> TeamCity that we use is responsible for creating a release branch and
> tagging. It is also the one that updates the repository and changes the
> version numbers automatically. It is going to be a problem because to do
> this it requires credentials on the Git repo. Is this something that we can
> ask to infra? Currently we use an authentication key, but user/password is
> also supported. Of course we could cheat and use our personal credentials,
> but ehm, if we can avoid this...
If it's for a technical commit, then I think the best - and easier -
would be to ask INFRA. If they don't want to create this special user,
then the simplest solution would be to use the Release Manager creds,
but I agree, that would be not really convenient.
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <ce...@gmail.com>.
Another issue I remembered this morning: the artifactory plugin for
TeamCity that we use is responsible for creating a release branch and
tagging. It is also the one that updates the repository and changes the
version numbers automatically. It is going to be a problem because to do
this it requires credentials on the Git repo. Is this something that we can
ask to infra? Currently we use an authentication key, but user/password is
also supported. Of course we could cheat and use our personal credentials,
but ehm, if we can avoid this...
2015-05-19 23:36 GMT+02:00 Emmanuel Lécharny <el...@gmail.com>:
> Le 19/05/15 21:36, Cédric Champeau a écrit :
> > Hi guys,
> >
> > I wanted to check with you what is preventing us from releasing 2.4.4.
> > Apart from the usual bugfixes, I think the necessary work on the source
> > code itself to match the Apache guidance has been done (in particular
> > licenses checks).
> >
> > From my perspective it should be possible to release using the "old
> > process" with subtle differences:
> >
> > - a release manager chosen from the IPMC will initiate the release
>
> So far, it's up to the PMC to decide who will be the RM, but OTOH, it
> can be anyone. There is no obligation for the ASF to nominate an
> official Release Manager, nor that he/she has to be part of the PMC.
> > - release will be done from the CI server
> > - binaries/sources/distributions will be signed automatically, as usual,
> > through Bintray
> > - Maven artifacts will be published automatically on Artifactory (OJO)
> >
> > So far, nothing differs from the usual process but:
> >
> > - Maven Central synchronization *will* be disabled, instead of done
> > automatically until now, so that we can cancel the release if it is
> > downvoted
> Usually, when we cut a release, it goes into a staging area, so if it's
> not voted, it can be removed. Is that an option ?
>
> > - Sources/distributions need to be copied manually from Bintray to [1] by
> > the release manager (attn mentors: how?)
>
> scp + commit. The dist are is managed with subversion.
>
>
> > - since we do not generate MD5 files through Gradle yet (it's not a
> > technical problem), the release manager should generate the checksums for
> > sources/distributions/binaries and upload them to [1] too. An open
> question
> > is whether those signatures should be generated in Bintray, in which case
> > we need support from them, or from our side, in which case we have to
> > update the build to generate them and make them artifacts.
>
> I do use my own little script to do that when I cut a release. It's
> dirty, it does the job.
>
> > - release manager announces on dev@ and voting starts
> in fact, the vote *is* an annoucement.
> > - if vote is positive, release manager asks IPMC to vote
>
> That's fine. The inner vote is quite informal (ie, no 72h, etc)
> > - if vote is positive, release manager triggers Maven Central
> > synchronization from Bintray and announces the release on the MLs
> That has to be the last step (ie, teh announcement). Because 200 mirrors
> have to be updated, and all of them might not be updated every hour,
> just be sure to wait 24h before any announcement.
> > - if vote is positive, website needs to be updated too [2]
> Yes, and that should be done when the packages have been moved, and 24h
> before the announcement.
> >
> > We have chosen to use a version number *without* -incubating for the
> > artifacts. Only the sources zip will have -incubating in the file name,
> as
> > the incubator policy mandates. The website download logic will have to be
> > adapted for this special case.
>
>
> What do you think?
>
>
> sounds good to me
>
>
>
Re: In shape for a 2.4.4 release?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/05/15 21:36, Cédric Champeau a écrit :
> Hi guys,
>
> I wanted to check with you what is preventing us from releasing 2.4.4.
> Apart from the usual bugfixes, I think the necessary work on the source
> code itself to match the Apache guidance has been done (in particular
> licenses checks).
>
> From my perspective it should be possible to release using the "old
> process" with subtle differences:
>
> - a release manager chosen from the IPMC will initiate the release
So far, it's up to the PMC to decide who will be the RM, but OTOH, it
can be anyone. There is no obligation for the ASF to nominate an
official Release Manager, nor that he/she has to be part of the PMC.
> - release will be done from the CI server
> - binaries/sources/distributions will be signed automatically, as usual,
> through Bintray
> - Maven artifacts will be published automatically on Artifactory (OJO)
>
> So far, nothing differs from the usual process but:
>
> - Maven Central synchronization *will* be disabled, instead of done
> automatically until now, so that we can cancel the release if it is
> downvoted
Usually, when we cut a release, it goes into a staging area, so if it's
not voted, it can be removed. Is that an option ?
> - Sources/distributions need to be copied manually from Bintray to [1] by
> the release manager (attn mentors: how?)
scp + commit. The dist are is managed with subversion.
> - since we do not generate MD5 files through Gradle yet (it's not a
> technical problem), the release manager should generate the checksums for
> sources/distributions/binaries and upload them to [1] too. An open question
> is whether those signatures should be generated in Bintray, in which case
> we need support from them, or from our side, in which case we have to
> update the build to generate them and make them artifacts.
I do use my own little script to do that when I cut a release. It's
dirty, it does the job.
> - release manager announces on dev@ and voting starts
in fact, the vote *is* an annoucement.
> - if vote is positive, release manager asks IPMC to vote
That's fine. The inner vote is quite informal (ie, no 72h, etc)
> - if vote is positive, release manager triggers Maven Central
> synchronization from Bintray and announces the release on the MLs
That has to be the last step (ie, teh announcement). Because 200 mirrors
have to be updated, and all of them might not be updated every hour,
just be sure to wait 24h before any announcement.
> - if vote is positive, website needs to be updated too [2]
Yes, and that should be done when the packages have been moved, and 24h
before the announcement.
>
> We have chosen to use a version number *without* -incubating for the
> artifacts. Only the sources zip will have -incubating in the file name, as
> the incubator policy mandates. The website download logic will have to be
> adapted for this special case.
What do you think?
sounds good to me
Re: In shape for a 2.4.4 release?
Posted by Cédric Champeau <cc...@apache.org>.
2015-05-19 21:59 GMT+02:00 Keegan Witt <ke...@gmail.com>:
> If they require -incubating in the filename, does that mean it'll be in
> the Maven coordinates as well? If so, that's unfortunate since there are
> many tools (like IntelliJ) that probably won't be able to automatically
> locate the source jar.
>
> No, the Maven coordinates will not change. Only the source zip will have
-incubating in the file name.
> -Keegan
>
> On Tue, May 19, 2015 at 3:36 PM, Cédric Champeau <cc...@apache.org>
> wrote:
>
>> Hi guys,
>>
>> I wanted to check with you what is preventing us from releasing 2.4.4.
>> Apart from the usual bugfixes, I think the necessary work on the source
>> code itself to match the Apache guidance has been done (in particular
>> licenses checks).
>>
>> From my perspective it should be possible to release using the "old
>> process" with subtle differences:
>>
>> - a release manager chosen from the IPMC will initiate the release
>> - release will be done from the CI server
>> - binaries/sources/distributions will be signed automatically, as usual,
>> through Bintray
>> - Maven artifacts will be published automatically on Artifactory (OJO)
>>
>> So far, nothing differs from the usual process but:
>>
>> - Maven Central synchronization *will* be disabled, instead of done
>> automatically until now, so that we can cancel the release if it is
>> downvoted
>> - Sources/distributions need to be copied manually from Bintray to [1] by
>> the release manager (attn mentors: how?)
>> - since we do not generate MD5 files through Gradle yet (it's not a
>> technical problem), the release manager should generate the checksums for
>> sources/distributions/binaries and upload them to [1] too. An open question
>> is whether those signatures should be generated in Bintray, in which case
>> we need support from them, or from our side, in which case we have to
>> update the build to generate them and make them artifacts.
>> - release manager announces on dev@ and voting starts
>> - if vote is positive, release manager asks IPMC to vote
>> - if vote is positive, release manager triggers Maven Central
>> synchronization from Bintray and announces the release on the MLs
>> - if vote is positive, website needs to be updated too [2]
>>
>> We have chosen to use a version number *without* -incubating for the
>> artifacts. Only the sources zip will have -incubating in the file name, as
>> the incubator policy mandates. The website download logic will have to be
>> adapted for this special case.
>>
>> What do you think?
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/groovy
>> [2] https://github.com/groovy/groovy-website
>>
>>
>
Re: In shape for a 2.4.4 release?
Posted by Andrew Bayer <an...@gmail.com>.
The Maven sources.jar will have the same version as the other Maven
artifacts - the sources zip referred to here is the source release
tarball/zipfile that is the only actual official Apache release artifact -
https://dist.apache.org/repos/dist/release/jclouds/1.9.0/, e.g.
A.
On Tue, May 19, 2015 at 12:59 PM, Keegan Witt <ke...@gmail.com> wrote:
> If they require -incubating in the filename, does that mean it'll be in
> the Maven coordinates as well? If so, that's unfortunate since there are
> many tools (like IntelliJ) that probably won't be able to automatically
> locate the source jar.
>
> -Keegan
>
> On Tue, May 19, 2015 at 3:36 PM, Cédric Champeau <cc...@apache.org>
> wrote:
>
>> Hi guys,
>>
>> I wanted to check with you what is preventing us from releasing 2.4.4.
>> Apart from the usual bugfixes, I think the necessary work on the source
>> code itself to match the Apache guidance has been done (in particular
>> licenses checks).
>>
>> From my perspective it should be possible to release using the "old
>> process" with subtle differences:
>>
>> - a release manager chosen from the IPMC will initiate the release
>> - release will be done from the CI server
>> - binaries/sources/distributions will be signed automatically, as usual,
>> through Bintray
>> - Maven artifacts will be published automatically on Artifactory (OJO)
>>
>> So far, nothing differs from the usual process but:
>>
>> - Maven Central synchronization *will* be disabled, instead of done
>> automatically until now, so that we can cancel the release if it is
>> downvoted
>> - Sources/distributions need to be copied manually from Bintray to [1] by
>> the release manager (attn mentors: how?)
>> - since we do not generate MD5 files through Gradle yet (it's not a
>> technical problem), the release manager should generate the checksums for
>> sources/distributions/binaries and upload them to [1] too. An open question
>> is whether those signatures should be generated in Bintray, in which case
>> we need support from them, or from our side, in which case we have to
>> update the build to generate them and make them artifacts.
>> - release manager announces on dev@ and voting starts
>> - if vote is positive, release manager asks IPMC to vote
>> - if vote is positive, release manager triggers Maven Central
>> synchronization from Bintray and announces the release on the MLs
>> - if vote is positive, website needs to be updated too [2]
>>
>> We have chosen to use a version number *without* -incubating for the
>> artifacts. Only the sources zip will have -incubating in the file name, as
>> the incubator policy mandates. The website download logic will have to be
>> adapted for this special case.
>>
>> What do you think?
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/groovy
>> [2] https://github.com/groovy/groovy-website
>>
>>
>
Re: In shape for a 2.4.4 release?
Posted by Keegan Witt <ke...@gmail.com>.
If they require -incubating in the filename, does that mean it'll be in the
Maven coordinates as well? If so, that's unfortunate since there are many
tools (like IntelliJ) that probably won't be able to automatically locate
the source jar.
-Keegan
On Tue, May 19, 2015 at 3:36 PM, Cédric Champeau <cc...@apache.org>
wrote:
> Hi guys,
>
> I wanted to check with you what is preventing us from releasing 2.4.4.
> Apart from the usual bugfixes, I think the necessary work on the source
> code itself to match the Apache guidance has been done (in particular
> licenses checks).
>
> From my perspective it should be possible to release using the "old
> process" with subtle differences:
>
> - a release manager chosen from the IPMC will initiate the release
> - release will be done from the CI server
> - binaries/sources/distributions will be signed automatically, as usual,
> through Bintray
> - Maven artifacts will be published automatically on Artifactory (OJO)
>
> So far, nothing differs from the usual process but:
>
> - Maven Central synchronization *will* be disabled, instead of done
> automatically until now, so that we can cancel the release if it is
> downvoted
> - Sources/distributions need to be copied manually from Bintray to [1] by
> the release manager (attn mentors: how?)
> - since we do not generate MD5 files through Gradle yet (it's not a
> technical problem), the release manager should generate the checksums for
> sources/distributions/binaries and upload them to [1] too. An open question
> is whether those signatures should be generated in Bintray, in which case
> we need support from them, or from our side, in which case we have to
> update the build to generate them and make them artifacts.
> - release manager announces on dev@ and voting starts
> - if vote is positive, release manager asks IPMC to vote
> - if vote is positive, release manager triggers Maven Central
> synchronization from Bintray and announces the release on the MLs
> - if vote is positive, website needs to be updated too [2]
>
> We have chosen to use a version number *without* -incubating for the
> artifacts. Only the sources zip will have -incubating in the file name, as
> the incubator policy mandates. The website download logic will have to be
> adapted for this special case.
>
> What do you think?
>
> [1] https://dist.apache.org/repos/dist/release/incubator/groovy
> [2] https://github.com/groovy/groovy-website
>
>