This is an automated email from the ASF dual-hosted git repository. lostluck pushed a commit to branch lostluck-go-roadmap in repository https://gitbox.apache.org/repos/asf/beam.git
commit 85af9fadd8f468b74ded62d0defc7ca5f0a84ec6 Author: Robert Burke <[email protected]> AuthorDate: Thu Mar 26 11:46:39 2020 -0700 Update the Go SDK roadmap for April 2020 --- website/src/roadmap/go-sdk.md | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/website/src/roadmap/go-sdk.md b/website/src/roadmap/go-sdk.md index c2e463c..29378e9 100644 --- a/website/src/roadmap/go-sdk.md +++ b/website/src/roadmap/go-sdk.md @@ -24,23 +24,29 @@ The Go SDK is currently experimental. As the first purely portable Beam SDK, the by the status of the [Beam Portabillity Framework](https://beam.apache.org/roadmap/portability/) and the existence of portable runners. -With that in mind present work on the Go SDK has the following goals: +**April 2020 Update** +This year we hope to move the SDK out of experimental at least for Batch usage. + +To do so, there are a few blocking changes: + * Support Interoperability with other SDKs + * Scalable IOs + * Portability Proto stability + * Go Ecosystem integration improvements + +Interoperability while not a blocking feature in itself, requires Beam Schema support, which +the SDK could then use as it's default coder. Batch Splittable DoFns are nearly ready for +playing with on Flink, and the Python Direct Runner, answering the scalable batch IO question. +There's much work getting the portability protos to a stable baseline. This will allow runner +and SDK independance, so they don't need to be updated in lockstep. Finally, the Go SDK should +adopt Go Modules as it's versioning solution, and officially "catch up" with the current beam +version. + +The Go SDK has the following goals for the next few months: ## Usability -The Go SDK should not block users from writing the pipelines they need to run. - -* Support large elements [BEAM-4124](https://issues.apache.org/jira/browse/BEAM-4124) -* Coder Registry to support complex user elements [BEAM-3306](https://issues.apache.org/jira/browse/BEAM-3306) - -## Performance - -Since the Go SDK has no official runner support at this time, this gives us the chance to work on the performance -of the SDK harness. When portable runners are ready, the Go SDK should be ready as well. - -* Reducing framework overhead on the SDK Harness side [BEAM-4726](https://issues.apache.org/jira/browse/BEAM-4726) -* Tooling to enable and verify pipeline performance [BEAM-3612](https://issues.apache.org/jira/browse/BEAM-3612) -* Measure the performance of the SDK at scale. +* Beam Schema Support [BEAM-9615](https://issues.apache.org/jira/browse/BEAM-4124) +* Improvements to starcgen [BEAM-9616](https://issues.apache.org/jira/browse/BEAM-9616) ## Integrating with the Go ecosystem @@ -68,5 +74,5 @@ Otherwise, improving examples and documentation for devs and users alike is ongo Contributions are welcome. Please contact the [dev list](mailto:[email protected]?subject=%5BGo%20SDK%5D%20How%20can%20I%20help%3F) for assistance in finding a place to help out. - - JIRA: [sdk-go](https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20component%20%3D%20sdk-go) / [BEAM-2083](https://issues.apache.org/jira/browse/BEAM-2083) + - JIRA: [sdk-go](https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20component%20%3D%20sdk-go) - Contact: Robert Burke (@lostluck) [Email](mailto:[email protected]?subject=%5BGo%20SDK%20Roadmap%5D) - Please also cc the [email protected] list. I strongly prefer public discussion of Go SDK matters.
