Cutting the next release branch is not equal to starting the release
vote. In the past we have cut the branch even if there are still open
issues and then give people some days to trim their issues.
So the release manager should create the release branch in the
specified date and sync with the
Nice doc. I really appreciate how it gives an overview of the code.
Kenn
On Fri, Jun 14, 2019 at 4:14 PM Anton Kedin wrote:
> Hi dev@, and especially anyone interested in SQL,
>
> We have an interface called TableProvider (and some other related classes)
> in Beam SQL that manages how we
Hi folks,
Just wanted to drop a note here on a new pattern that folks may find
interesting, called Looping Timers. It allows for default values to be
created in interval windows in the absence of any external data coming into
the pipeline. The details are in this blog below:
On Tue, Jun 18, 2019 at 6:00 PM Anton Kedin wrote:
> What is the right thing to do if it is not ready by the proposed branch
> cut time tomorrow? I don't think the Jira issue provides enough context
> about the severity of the problem and why it has to go out specifically in
> 2.14.0. Without
What is the right thing to do if it is not ready by the proposed branch cut
time tomorrow? I don't think the Jira issue provides enough context about
the severity of the problem and why it has to go out specifically in
2.14.0. Without additional context I think the expected path forward should
Please note that https://issues.apache.org/jira/browse/BEAM-7424 was marked
as a blocker and we'd like to get the fix to Python SDK into the 2.14
release.
Thanks,
Cham
On Tue, Jun 18, 2019 at 4:16 PM Anton Kedin wrote:
> It's a reminder, I am planning to cut the release branch tomorrow, on
>
It's a reminder, I am planning to cut the release branch tomorrow, on
Wednesday, June 19, at 11am PDT (Seattle local time, corresponds to
[19:00@GMT+1] and [18:00@UTC]). Please make sure all the code you want in
the release is submitted by that time, and that all blocking Jiras have the
release
Thank you for the update, very helpful. It might be worthwhile to share a
version of this with user mailing list after 2.14.
Remaining question for me is: There is no plan for an LTS release
currently. Would it make sense for us to target one after known remaining
issues are mostly fixed. What
Thanks for updating that alternative.
As for the to/from functions, it does seem pragmatic to dangle them
off the purely portable representation (either as a field there, or as
an opaque logical type whose payload contains the to/from functions,
or a separate coder that wraps the schema coder
To give a better understanding where we are w.r.t. Python 3, I'd like to
give a quick overview of the recent work that has been happening in Beam
community to support Python 3, and to summarize the current status of this
effort.
Current status:
1.
Beam 2.11.0 was the first release that
Thanx!
It would definitely be great to have the ability for folks adding utility /
extensions to be able to have them run against all runners.
Cheers
Reza
On Fri, 7 Jun 2019, 19:05 Lukasz Cwik, wrote:
> We have been currently been having every runner define and manage its own
> suite/tests so
I like the update Ismaël referenced [1], I think we should prepare a
similar update for Beam users. I would propose the following:
- Designate last LTS release that we will have in 2019 to be the last LTS
release with Python 2 support.
- Add a Beam-specific deprecation warning on Python 2 starting
12 matches
Mail list logo
