Joining in just a bit late, I'll be quick and say that IMHO the SDK is mature enough and so my only point to add is *HDFS support*. I think that in terms of adoption we have to support HDFS as a "first-class citizen" via the FileSystem API, and provide data locality (batch) on top of it - it serves not only HDFS, but other eco-system IOs such as HBase. >From my experience with talking to people and companies, most are running batch in production with some streaming POC or even production use, but batch still takes most of production work. If we give them the same production results, with the Beam API, we can on-board them faster and make it easier for them to adopt streaming as well.
Thanks, Amit On Tue, Feb 28, 2017 at 7:12 PM Davor Bonaci <da...@apache.org> wrote: > Alright -- sounds like we have a consensus to proceed with the first stable > release after 0.6.0, targeting end of March / early April. I'll kick off > separate threads for specific decisions we need to make. > > On Thu, Feb 23, 2017 at 6:07 AM, Aljoscha Krettek <aljos...@apache.org> > wrote: > > > I think we're ready for this! The public APIs are in very good shape, > > especially now that we have the new DoFn, user facing state and timers > and > > splittable DoFn. Not all Runners support the more advanced features but > we > > can work on this after a stable release and there are enough runners that > > support a large part of the features. > > > > Best, > > Aljoscha > > > > On Thu, 23 Feb 2017 at 06:15 Kenneth Knowles <k...@google.com.invalid> > > wrote: > > > > > On Wed, Feb 22, 2017 at 5:35 PM, Chamikara Jayalath < > > chamik...@apache.org> > > > wrote: > > > > > > > > I think, this point applies to Python SDK as well (though as you > > > mentioned, > > > > API hiding in Python is a mere convention (prefix with underscore) > not > > > > enforced. We already have mechanism for marking APIs as deprecated > > which > > > > might be useful here: > > > > https://github.com/apache/beam/blob/master/sdks/python/ > > > > apache_beam/utils/annotations.py > > > > > > > > - Cham > > > > > > > > > > Perhaps an explicit @public annotation would fit. I could imagine > easily > > > generating a spec to check against from such annotations, though > tooling > > is > > > secondary to documentation. > > > > > > Kenn > > > > > >
