Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

My wishlist for 2018 would be - Python 3 support - Python SDK to work with more runners. This is covered in portability in general. I would like to see an enterprise grade Python SDK that can run on a range of Beam runners. - Related to the above item, full streaming support with Python SDK. -

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

Ps: forgot another wish: make usable beam sql. Today you need to add a fn before and after cause of that type breakage not consistent with the pipeline API. It would be nice to support pojo (extracted from the select fields or created from "views" like in jackson) bit not having to wrap the sql

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

My user wishes - whatever version, it is just a number after all ;): - make coder usage simpler and consistent (PCollection TypeDescriptor and Coder are duplicated in term of API) - have a beam api (split from the sdk and internals and impl) - have SDF supported by runners - have a SDFRunner

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

On Tue, Nov 28, 2017 at 9:48 AM, Reuven Lax wrote: > > On Tue, Nov 28, 2017 at 9:14 AM, Jean-Baptiste Onofré > wrote: >> >> Hi Reuven, >> >> Yes, I remember that we agreed on a release per month. However, we didn't >> do it before. I think the most important

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

I would suggest that for 3.x we target portability so that more runners can execute an Apache Beam python pipeline. We should start targeting JIRAs which we know are backwards incompatible as well since we know there are rough corners around some APIs. On Tue, Nov 28, 2017 at 9:48 AM, Reuven

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

On Tue, Nov 28, 2017 at 9:14 AM, Jean-Baptiste Onofré wrote: > Hi Reuven, > > Yes, I remember that we agreed on a release per month. However, we didn't > do it before. I think the most important is not the period, it's more a > stable pace. I think it's more interesting for

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

+1 for monthly release if we can sustain this pace ;) Fully agree to improve the test, automation, documentation of the release process. On 11/28/2017 06:25 PM, Kenneth Knowles wrote: Yea, let's work hard on improving the ease and pace of releases. I am not really happy to have only quarterly

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

Strong +1 to both increasing the frequency of minor releases and also putting together a road map for the next major release or two. I think it would be great to communicate to the community the direction Beam is taking in the future -- what things will users be able to do with 3.0 or 4.0 that

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

Yea, let's work hard on improving the ease and pace of releases. I am not really happy to have only quarterly releases. Automation of release process where possible, better test coverage, a higher resistance to cherry-picks. Kenn On Tue, Nov 28, 2017 at 9:14 AM, Jean-Baptiste Onofré

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

Hi Reuven, Yes, I remember that we agreed on a release per month. However, we didn't do it before. I think the most important is not the period, it's more a stable pace. I think it's more interesting for our community to have "always" a release every two months, more than a tentative of a

Re: [DISCUSS] Thinking about Beam 3.x roadmap and release schedule

On Tue, Nov 28, 2017 at 8:55 AM, Jean-Baptiste Onofré wrote: > Hi guys, > > Even if there's no rush, I think it would be great for the community to > have a better view on our roadmap and where we are going in term of > schedule. > > I would like to discuss the following: > -

[DISCUSS] Thinking about Beam 3.x roadmap and release schedule

Hi guys, Even if there's no rush, I think it would be great for the community to have a better view on our roadmap and where we are going in term of schedule. I would like to discuss the following: - a best effort to maintain a good release pace or at least provide a rough schedule. For