Re: 0.1.0-incubating release

The third release candidate is now available for everyone's review [1], which should be incorporating all feedback so far. Please comment if there's additional feedback, as we are about to start the voting process. [1] https://repository.apache.org/content/repositories/orgapachebeam-1002 On

Re: 0.1.0-incubating release

Thanks for the clarification JB. In the projects I’ve been involved with, I’ve not seen that practice. As long as the resulting release ends up on dist.a.o I don’t think it’s a problem. -Taylor > On Jun 8, 2016, at 12:49 AM, Jean-Baptiste Onofré wrote: > > Hi Taylor, >

Re: 0.1.0-incubating release

To Davor, JB and anyone else helping with the release, Thanks! this looks great. On Wed, Jun 8, 2016 at 9:11 PM Amit Sela wrote: > Regarding Dan's questions: > 1. I'm not sure - it is built with spark-*_2.10 but I honestly don't know > if this matters for the runner

Re: 0.1.0-incubating release

Regarding Dan's questions: 1. I'm not sure - it is built with spark-*_2.10 but I honestly don't know if this matters for the runner itself, it could be nice to have in order to be more informative. In addition, this will change with Spark 2.0 to Scala 2.11 AFAIK. 2. This is to allow running

Re: 0.1.0-incubating release

Out of curiosity, is there a reason for distributing the release on repository.a.o vs. dist.a.o? In my experience repository.a.o has traditionally been used for maven artifacts, and dist.a.o has been for release artifacts (source archives and convenience binaries). I'd be happy to help with

Re: 0.1.0-incubating release

Aljoscha, if you want to be sure and want only one RC like me, I'd suggest you search general incubator mail archive and look for comments from Justin & Sebb - they are very thorough and will give you a headstart instead of iterating multiple times. On Tue, Jun 7, 2016 at 12:59 PM Jean-Baptiste

Re: 0.1.0-incubating release

By the way, is there any document where we keep track of what checks to run for a release? Maybe I missed something, there. On Tue, 7 Jun 2016 at 21:29 Jean-Baptiste Onofré wrote: > Just submitted: https://github.com/apache/incubator-beam/pull/428 > > to fix the src

Re: 0.1.0-incubating release

I have to revert my vote to -1: the source distribution zip file is empty. I gonna submit a new PR to fix that. Sorry about that. Regards JB On 06/07/2016 09:12 PM, Jean-Baptiste Onofré wrote: +1 it looks good to me: - all files have incubating - signatures check out (asc, md5, sha1) (and

Re: 0.1.0-incubating release

+1 it looks good to me: - all files have incubating - signatures check out (asc, md5, sha1) (and KEYS there) - disclaimer exists - LICENSE and NOTICE good - No unexpected binary in source - All ASF licensed files have ASF headers - Source distribution is available, with a correct name, and

Re: 0.1.0-incubating release

+1 Lovely. Very readable. The "-parent" artifacts are just leaked implementation details of our build configuration that no one should ever actually reference, right? Kenn On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin wrote: > +2! This seems most concordant with

Re: 0.1.0-incubating release

+1 On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin wrote: > +2! This seems most concordant with other Apache products and the most > future-proof. > > On Mon, Jun 6, 2016 at 9:35 PM, Jean-Baptiste Onofré > wrote: > > > +1 > > > > Regards > > JB > >

Re: 0.1.0-incubating release

+1 Regards JB On 06/07/2016 02:49 AM, Davor Bonaci wrote: After a few rounds of discussions and examining patterns of other projects, I think we are converging towards: * A flat group structure, where all artifacts belong to the org.apache.beam group. * Prefix all artifact ids with "beam-". *

Re: 0.1.0-incubating release

Another consideration for potential future packaging/distribution solutions is how the artifacts line up as files in a flat directory. For that it may be good to have a common prefix in the artifactId and unique artifactId. The name for the source archive (when relying on ASF parent POM) can also

Re: 0.1.0-incubating release

Hi Max, I discussed with Davor yesterday. Basically, I proposed: 1. To rename all parent with a prefix (beam-parent, flink-runner-parent, spark-runner-parent, etc). 2. For the groupId, I prefer to use different groupId, it's clearer to me, and it's exactly the usage of the groupId. Some

Re: 0.1.0-incubating release

Another annoying thing is the main parent POM artifactId. Now, it's just "parent". What do you think about renaming to "beam-parent" ? Regarding the source distribution name, I would cancel this staging to fix that (I will have a PR ready soon). Thoughts ? Regards JB On 06/02/2016 03:46