You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Robert Bradshaw <ro...@google.com> on 2018/02/20 20:50:08 UTC
Beam 2.4.0
Now that Beam 2.3.0 went out (and in record time, kudos to all that
made this happen!) It'd be great to keep the ball rolling for a
similarly well-executed 2.4. A lot has gone in [1] since we made the
2.3 cut, and to keep our cadence up I would propose a time-based cut
date early next week (say the 28th).
I'll volunteer to do this release.
[1] https://github.com/apache/beam/compare/release-2.3.0...master
Re: Beam 2.4.0
Posted by Rafael Fernandez <rf...@google.com>.
+1 on having release trains scheduled.
Romain: Do you have a list of PRs that could benefit from increased focus
if they want to make it on the upcoming train?
On Tue, Feb 20, 2018 at 3:30 PM Ahmet Altay <al...@google.com> wrote:
> +1 for having regular release cycles. Finalizing a release takes time in
> the order of a few weeks and starting a new release soon after the previous
> one is a reliable way for having releases every 6 weeks.
>
> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
> wrote:
>
>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>
>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>> > I would like to +1 the faster release cycle process JB and Robert have
>> been
>> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
>> > When we block for specific features and increase the time between
>> releases,
>> > we increase the urgency for PR authors to push for their change to go
>> into
>> > an upcoming release, which is a feedback loop that results in our
>> releases
>> > taking months instead of weeks. We should however try to get pending
>> PRs
>> > wrapped up.
>> >
>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >>
>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just
>> out
>> >> so 1 week is a bit fast IMHO.
>> >>
>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>> écrit :
>> >>>
>> >>> One of the main shifts that I think helped this release was explicitly
>> >>> not being feature driven, rather releasing what's already in the
>> >>> branch. That doesn't mean it's not a good call to action to try and
>> >>> get long-pending PRs or similar wrapped up.
>> >>>
>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>> >>> <rm...@gmail.com> wrote:
>> >>> > There are a lot of long pending PR, would be good to merge them
>> before
>> >>> > 2.4.
>> >>> > Some are bringing tests for the 2.3 release which can be critical to
>> >>> > include.
>> >>> >
>> >>> > Maybe we should list the pr and jira we want it before picking a
>> date?
>> >>> >
>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>> katsiapis@google.com>
>> >>> > a
>> >>> > écrit :
>> >>> >>
>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
>> (and
>> >>> >> the
>> >>> >> latter already has an RC out, so we will likely be blocked on
>> Beam).
>> >>> >>
>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>> >>> >> <ro...@google.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all
>> that
>> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made
>> the
>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based
>> cut
>> >>> >>> date early next week (say the 28th).
>> >>> >>>
>> >>> >>> I'll volunteer to do this release.
>> >>> >>>
>> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>> >>> >> 650-918-7487
>>
>
>
Re: Beam 2.4.0
Posted by Ahmet Altay <al...@google.com>.
+1 for having regular release cycles. Finalizing a release takes time in
the order of a few weeks and starting a new release soon after the previous
one is a reliable way for having releases every 6 weeks.
On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
wrote:
> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
> exactly 6 weeks after JB first started the 2.3.0 release thread.
>
> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
> > I would like to +1 the faster release cycle process JB and Robert have
> been
> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
> > When we block for specific features and increase the time between
> releases,
> > we increase the urgency for PR authors to push for their change to go
> into
> > an upcoming release, which is a feedback loop that results in our
> releases
> > taking months instead of weeks. We should however try to get pending PRs
> > wrapped up.
> >
> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >>
> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just out
> >> so 1 week is a bit fast IMHO.
> >>
> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
> écrit :
> >>>
> >>> One of the main shifts that I think helped this release was explicitly
> >>> not being feature driven, rather releasing what's already in the
> >>> branch. That doesn't mean it's not a good call to action to try and
> >>> get long-pending PRs or similar wrapped up.
> >>>
> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
> >>> <rm...@gmail.com> wrote:
> >>> > There are a lot of long pending PR, would be good to merge them
> before
> >>> > 2.4.
> >>> > Some are bringing tests for the 2.3 release which can be critical to
> >>> > include.
> >>> >
> >>> > Maybe we should list the pr and jira we want it before picking a
> date?
> >>> >
> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
> katsiapis@google.com>
> >>> > a
> >>> > écrit :
> >>> >>
> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
> (and
> >>> >> the
> >>> >> latter already has an RC out, so we will likely be blocked on Beam).
> >>> >>
> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
> >>> >> <ro...@google.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made
> the
> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based
> cut
> >>> >>> date early next week (say the 28th).
> >>> >>>
> >>> >>> I'll volunteer to do this release.
> >>> >>>
> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
> >>> >> 650-918-7487
>
Re: Beam 2.4.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
done
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
2018-02-21 18:31 GMT+01:00 Kenneth Knowles <kl...@google.com>:
> *are _not_ on the burndown :-)
>
> On Wed, Feb 21, 2018 at 9:31 AM, Kenneth Knowles <kl...@google.com> wrote:
>
>> Romain - it looks like these JIRA tickets are on on the 2.4.0 burndown.
>> Can you set their Fix Version field to make sure they are tracked and
>> triaged?
>>
>>
>> On Tue, Feb 20, 2018 at 10:22 PM, Reuven Lax <re...@google.com> wrote:
>>
>>> I think it's fair to request that the reviewers of these PRs help with
>>> your effort to get them merged before the 2.4.0 cut. Existing comments on
>>> the PR imply that reviewers think the approaches are reasonable. Assuming
>>> that there's not too much work left to be done to address comments, there's
>>> a good chance of getting them in.
>>>
>>> Reuven
>>>
>>> On Tue, Feb 20, 2018 at 10:10 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>> Ok
>>>>
>>>> In terms of what I'd like included, here is the list:
>>>>
>>>> 1. https://github.com/apache/beam/pull/4412 (important to prevent
>>>> regressions)
>>>> 2. https://github.com/apache/beam/pull/4674 (can need some more work
>>>> but can break some api if we do, so current state is a functional trade
>>>> off). On a more personal side Im blocked by this one for some features.
>>>> 3. https://github.com/apache/beam/pull/4372 (important cause doesnt
>>>> make the execution deterministic depending your surefire config, IDE, main
>>>> usage)
>>>>
>>>>
>>>>
>>>> Le 21 févr. 2018 01:29, "Reuven Lax" <re...@google.com> a écrit :
>>>>
>>>>> +1, this is keeping with an every-six weeks cadence.
>>>>>
>>>>> Romain, you can always target Jiras to this release, and then the
>>>>> release manager can decide on a case-by-case basis whether to make sure the
>>>>> fix is included.
>>>>>
>>>>> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
>>>>> wrote:
>>>>>
>>>>>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>>>>>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>>>>>
>>>>>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>>>>>> > I would like to +1 the faster release cycle process JB and Robert
>>>>>> have been
>>>>>> > advocating and implementing, and thank JB for releasing 2.3.0
>>>>>> smoothly.
>>>>>> > When we block for specific features and increase the time between
>>>>>> releases,
>>>>>> > we increase the urgency for PR authors to push for their change to
>>>>>> go into
>>>>>> > an upcoming release, which is a feedback loop that results in our
>>>>>> releases
>>>>>> > taking months instead of weeks. We should however try to get
>>>>>> pending PRs
>>>>>> > wrapped up.
>>>>>> >
>>>>>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is
>>>>>> just out
>>>>>> >> so 1 week is a bit fast IMHO.
>>>>>> >>
>>>>>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>>>>>> écrit :
>>>>>> >>>
>>>>>> >>> One of the main shifts that I think helped this release was
>>>>>> explicitly
>>>>>> >>> not being feature driven, rather releasing what's already in the
>>>>>> >>> branch. That doesn't mean it's not a good call to action to try
>>>>>> and
>>>>>> >>> get long-pending PRs or similar wrapped up.
>>>>>> >>>
>>>>>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>>>>>> >>> <rm...@gmail.com> wrote:
>>>>>> >>> > There are a lot of long pending PR, would be good to merge them
>>>>>> before
>>>>>> >>> > 2.4.
>>>>>> >>> > Some are bringing tests for the 2.3 release which can be
>>>>>> critical to
>>>>>> >>> > include.
>>>>>> >>> >
>>>>>> >>> > Maybe we should list the pr and jira we want it before picking
>>>>>> a date?
>>>>>> >>> >
>>>>>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>>>>>> katsiapis@google.com>
>>>>>> >>> > a
>>>>>> >>> > écrit :
>>>>>> >>> >>
>>>>>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow
>>>>>> 1.6 (and
>>>>>> >>> >> the
>>>>>> >>> >> latter already has an RC out, so we will likely be blocked on
>>>>>> Beam).
>>>>>> >>> >>
>>>>>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>>>>>> >>> >> <ro...@google.com>
>>>>>> >>> >> wrote:
>>>>>> >>> >>>
>>>>>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to
>>>>>> all that
>>>>>> >>> >>> made this happen!) It'd be great to keep the ball rolling for
>>>>>> a
>>>>>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we
>>>>>> made the
>>>>>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a
>>>>>> time-based cut
>>>>>> >>> >>> date early next week (say the 28th).
>>>>>> >>> >>>
>>>>>> >>> >>> I'll volunteer to do this release.
>>>>>> >>> >>>
>>>>>> >>> >>> [1] https://github.com/apache/beam
>>>>>> /compare/release-2.3.0...master
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >> --
>>>>>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>>>>>> >>> >> 650-918-7487
>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: Beam 2.4.0
Posted by Kenneth Knowles <kl...@google.com>.
*are _not_ on the burndown :-)
On Wed, Feb 21, 2018 at 9:31 AM, Kenneth Knowles <kl...@google.com> wrote:
> Romain - it looks like these JIRA tickets are on on the 2.4.0 burndown.
> Can you set their Fix Version field to make sure they are tracked and
> triaged?
>
>
> On Tue, Feb 20, 2018 at 10:22 PM, Reuven Lax <re...@google.com> wrote:
>
>> I think it's fair to request that the reviewers of these PRs help with
>> your effort to get them merged before the 2.4.0 cut. Existing comments on
>> the PR imply that reviewers think the approaches are reasonable. Assuming
>> that there's not too much work left to be done to address comments, there's
>> a good chance of getting them in.
>>
>> Reuven
>>
>> On Tue, Feb 20, 2018 at 10:10 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>> Ok
>>>
>>> In terms of what I'd like included, here is the list:
>>>
>>> 1. https://github.com/apache/beam/pull/4412 (important to prevent
>>> regressions)
>>> 2. https://github.com/apache/beam/pull/4674 (can need some more work
>>> but can break some api if we do, so current state is a functional trade
>>> off). On a more personal side Im blocked by this one for some features.
>>> 3. https://github.com/apache/beam/pull/4372 (important cause doesnt
>>> make the execution deterministic depending your surefire config, IDE, main
>>> usage)
>>>
>>>
>>>
>>> Le 21 févr. 2018 01:29, "Reuven Lax" <re...@google.com> a écrit :
>>>
>>>> +1, this is keeping with an every-six weeks cadence.
>>>>
>>>> Romain, you can always target Jiras to this release, and then the
>>>> release manager can decide on a case-by-case basis whether to make sure the
>>>> fix is included.
>>>>
>>>> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
>>>> wrote:
>>>>
>>>>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>>>>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>>>>
>>>>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>>>>> > I would like to +1 the faster release cycle process JB and Robert
>>>>> have been
>>>>> > advocating and implementing, and thank JB for releasing 2.3.0
>>>>> smoothly.
>>>>> > When we block for specific features and increase the time between
>>>>> releases,
>>>>> > we increase the urgency for PR authors to push for their change to
>>>>> go into
>>>>> > an upcoming release, which is a feedback loop that results in our
>>>>> releases
>>>>> > taking months instead of weeks. We should however try to get
>>>>> pending PRs
>>>>> > wrapped up.
>>>>> >
>>>>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is
>>>>> just out
>>>>> >> so 1 week is a bit fast IMHO.
>>>>> >>
>>>>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>>>>> écrit :
>>>>> >>>
>>>>> >>> One of the main shifts that I think helped this release was
>>>>> explicitly
>>>>> >>> not being feature driven, rather releasing what's already in the
>>>>> >>> branch. That doesn't mean it's not a good call to action to try and
>>>>> >>> get long-pending PRs or similar wrapped up.
>>>>> >>>
>>>>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>>>>> >>> <rm...@gmail.com> wrote:
>>>>> >>> > There are a lot of long pending PR, would be good to merge them
>>>>> before
>>>>> >>> > 2.4.
>>>>> >>> > Some are bringing tests for the 2.3 release which can be
>>>>> critical to
>>>>> >>> > include.
>>>>> >>> >
>>>>> >>> > Maybe we should list the pr and jira we want it before picking a
>>>>> date?
>>>>> >>> >
>>>>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>>>>> katsiapis@google.com>
>>>>> >>> > a
>>>>> >>> > écrit :
>>>>> >>> >>
>>>>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow
>>>>> 1.6 (and
>>>>> >>> >> the
>>>>> >>> >> latter already has an RC out, so we will likely be blocked on
>>>>> Beam).
>>>>> >>> >>
>>>>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>>>>> >>> >> <ro...@google.com>
>>>>> >>> >> wrote:
>>>>> >>> >>>
>>>>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all
>>>>> that
>>>>> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
>>>>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we
>>>>> made the
>>>>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a
>>>>> time-based cut
>>>>> >>> >>> date early next week (say the 28th).
>>>>> >>> >>>
>>>>> >>> >>> I'll volunteer to do this release.
>>>>> >>> >>>
>>>>> >>> >>> [1] https://github.com/apache/beam
>>>>> /compare/release-2.3.0...master
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >> --
>>>>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>>>>> >>> >> 650-918-7487
>>>>>
>>>>
>>>>
>>
>
Re: Beam 2.4.0
Posted by Kenneth Knowles <kl...@google.com>.
Romain - it looks like these JIRA tickets are on on the 2.4.0 burndown. Can
you set their Fix Version field to make sure they are tracked and triaged?
On Tue, Feb 20, 2018 at 10:22 PM, Reuven Lax <re...@google.com> wrote:
> I think it's fair to request that the reviewers of these PRs help with
> your effort to get them merged before the 2.4.0 cut. Existing comments on
> the PR imply that reviewers think the approaches are reasonable. Assuming
> that there's not too much work left to be done to address comments, there's
> a good chance of getting them in.
>
> Reuven
>
> On Tue, Feb 20, 2018 at 10:10 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>> Ok
>>
>> In terms of what I'd like included, here is the list:
>>
>> 1. https://github.com/apache/beam/pull/4412 (important to prevent
>> regressions)
>> 2. https://github.com/apache/beam/pull/4674 (can need some more work but
>> can break some api if we do, so current state is a functional trade off).
>> On a more personal side Im blocked by this one for some features.
>> 3. https://github.com/apache/beam/pull/4372 (important cause doesnt make
>> the execution deterministic depending your surefire config, IDE, main usage)
>>
>>
>>
>> Le 21 févr. 2018 01:29, "Reuven Lax" <re...@google.com> a écrit :
>>
>>> +1, this is keeping with an every-six weeks cadence.
>>>
>>> Romain, you can always target Jiras to this release, and then the
>>> release manager can decide on a case-by-case basis whether to make sure the
>>> fix is included.
>>>
>>> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
>>> wrote:
>>>
>>>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>>>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>>>
>>>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>>>> > I would like to +1 the faster release cycle process JB and Robert
>>>> have been
>>>> > advocating and implementing, and thank JB for releasing 2.3.0
>>>> smoothly.
>>>> > When we block for specific features and increase the time between
>>>> releases,
>>>> > we increase the urgency for PR authors to push for their change to go
>>>> into
>>>> > an upcoming release, which is a feedback loop that results in our
>>>> releases
>>>> > taking months instead of weeks. We should however try to get pending
>>>> PRs
>>>> > wrapped up.
>>>> >
>>>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just
>>>> out
>>>> >> so 1 week is a bit fast IMHO.
>>>> >>
>>>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>>>> écrit :
>>>> >>>
>>>> >>> One of the main shifts that I think helped this release was
>>>> explicitly
>>>> >>> not being feature driven, rather releasing what's already in the
>>>> >>> branch. That doesn't mean it's not a good call to action to try and
>>>> >>> get long-pending PRs or similar wrapped up.
>>>> >>>
>>>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>>>> >>> <rm...@gmail.com> wrote:
>>>> >>> > There are a lot of long pending PR, would be good to merge them
>>>> before
>>>> >>> > 2.4.
>>>> >>> > Some are bringing tests for the 2.3 release which can be critical
>>>> to
>>>> >>> > include.
>>>> >>> >
>>>> >>> > Maybe we should list the pr and jira we want it before picking a
>>>> date?
>>>> >>> >
>>>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>>>> katsiapis@google.com>
>>>> >>> > a
>>>> >>> > écrit :
>>>> >>> >>
>>>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
>>>> (and
>>>> >>> >> the
>>>> >>> >> latter already has an RC out, so we will likely be blocked on
>>>> Beam).
>>>> >>> >>
>>>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>>>> >>> >> <ro...@google.com>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all
>>>> that
>>>> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
>>>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we
>>>> made the
>>>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a
>>>> time-based cut
>>>> >>> >>> date early next week (say the 28th).
>>>> >>> >>>
>>>> >>> >>> I'll volunteer to do this release.
>>>> >>> >>>
>>>> >>> >>> [1] https://github.com/apache/beam
>>>> /compare/release-2.3.0...master
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> --
>>>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>>>> >>> >> 650-918-7487
>>>>
>>>
>>>
>
Re: Beam 2.4.0
Posted by Reuven Lax <re...@google.com>.
I think it's fair to request that the reviewers of these PRs help with your
effort to get them merged before the 2.4.0 cut. Existing comments on the PR
imply that reviewers think the approaches are reasonable. Assuming that
there's not too much work left to be done to address comments, there's a
good chance of getting them in.
Reuven
On Tue, Feb 20, 2018 at 10:10 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Ok
>
> In terms of what I'd like included, here is the list:
>
> 1. https://github.com/apache/beam/pull/4412 (important to prevent
> regressions)
> 2. https://github.com/apache/beam/pull/4674 (can need some more work but
> can break some api if we do, so current state is a functional trade off).
> On a more personal side Im blocked by this one for some features.
> 3. https://github.com/apache/beam/pull/4372 (important cause doesnt make
> the execution deterministic depending your surefire config, IDE, main usage)
>
>
>
> Le 21 févr. 2018 01:29, "Reuven Lax" <re...@google.com> a écrit :
>
>> +1, this is keeping with an every-six weeks cadence.
>>
>> Romain, you can always target Jiras to this release, and then the release
>> manager can decide on a case-by-case basis whether to make sure the fix is
>> included.
>>
>> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
>> wrote:
>>
>>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>>
>>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>>> > I would like to +1 the faster release cycle process JB and Robert have
>>> been
>>> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
>>> > When we block for specific features and increase the time between
>>> releases,
>>> > we increase the urgency for PR authors to push for their change to go
>>> into
>>> > an upcoming release, which is a feedback loop that results in our
>>> releases
>>> > taking months instead of weeks. We should however try to get pending
>>> PRs
>>> > wrapped up.
>>> >
>>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>> > wrote:
>>> >>
>>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just
>>> out
>>> >> so 1 week is a bit fast IMHO.
>>> >>
>>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>>> écrit :
>>> >>>
>>> >>> One of the main shifts that I think helped this release was
>>> explicitly
>>> >>> not being feature driven, rather releasing what's already in the
>>> >>> branch. That doesn't mean it's not a good call to action to try and
>>> >>> get long-pending PRs or similar wrapped up.
>>> >>>
>>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>>> >>> <rm...@gmail.com> wrote:
>>> >>> > There are a lot of long pending PR, would be good to merge them
>>> before
>>> >>> > 2.4.
>>> >>> > Some are bringing tests for the 2.3 release which can be critical
>>> to
>>> >>> > include.
>>> >>> >
>>> >>> > Maybe we should list the pr and jira we want it before picking a
>>> date?
>>> >>> >
>>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>>> katsiapis@google.com>
>>> >>> > a
>>> >>> > écrit :
>>> >>> >>
>>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
>>> (and
>>> >>> >> the
>>> >>> >> latter already has an RC out, so we will likely be blocked on
>>> Beam).
>>> >>> >>
>>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>>> >>> >> <ro...@google.com>
>>> >>> >> wrote:
>>> >>> >>>
>>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all
>>> that
>>> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
>>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made
>>> the
>>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based
>>> cut
>>> >>> >>> date early next week (say the 28th).
>>> >>> >>>
>>> >>> >>> I'll volunteer to do this release.
>>> >>> >>>
>>> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...maste
>>> r
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> --
>>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>>> >>> >> 650-918-7487
>>>
>>
>>
Re: Beam 2.4.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok
In terms of what I'd like included, here is the list:
1. https://github.com/apache/beam/pull/4412 (important to prevent
regressions)
2. https://github.com/apache/beam/pull/4674 (can need some more work but
can break some api if we do, so current state is a functional trade off).
On a more personal side Im blocked by this one for some features.
3. https://github.com/apache/beam/pull/4372 (important cause doesnt make
the execution deterministic depending your surefire config, IDE, main usage)
Le 21 févr. 2018 01:29, "Reuven Lax" <re...@google.com> a écrit :
> +1, this is keeping with an every-six weeks cadence.
>
> Romain, you can always target Jiras to this release, and then the release
> manager can decide on a case-by-case basis whether to make sure the fix is
> included.
>
> On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
> wrote:
>
>> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
>> exactly 6 weeks after JB first started the 2.3.0 release thread.
>>
>> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
>> > I would like to +1 the faster release cycle process JB and Robert have
>> been
>> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
>> > When we block for specific features and increase the time between
>> releases,
>> > we increase the urgency for PR authors to push for their change to go
>> into
>> > an upcoming release, which is a feedback loop that results in our
>> releases
>> > taking months instead of weeks. We should however try to get pending
>> PRs
>> > wrapped up.
>> >
>> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >>
>> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just
>> out
>> >> so 1 week is a bit fast IMHO.
>> >>
>> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
>> écrit :
>> >>>
>> >>> One of the main shifts that I think helped this release was explicitly
>> >>> not being feature driven, rather releasing what's already in the
>> >>> branch. That doesn't mean it's not a good call to action to try and
>> >>> get long-pending PRs or similar wrapped up.
>> >>>
>> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>> >>> <rm...@gmail.com> wrote:
>> >>> > There are a lot of long pending PR, would be good to merge them
>> before
>> >>> > 2.4.
>> >>> > Some are bringing tests for the 2.3 release which can be critical to
>> >>> > include.
>> >>> >
>> >>> > Maybe we should list the pr and jira we want it before picking a
>> date?
>> >>> >
>> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
>> katsiapis@google.com>
>> >>> > a
>> >>> > écrit :
>> >>> >>
>> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
>> (and
>> >>> >> the
>> >>> >> latter already has an RC out, so we will likely be blocked on
>> Beam).
>> >>> >>
>> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>> >>> >> <ro...@google.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all
>> that
>> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
>> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made
>> the
>> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based
>> cut
>> >>> >>> date early next week (say the 28th).
>> >>> >>>
>> >>> >>> I'll volunteer to do this release.
>> >>> >>>
>> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>> >>> >> 650-918-7487
>>
>
>
Re: Beam 2.4.0
Posted by Reuven Lax <re...@google.com>.
+1, this is keeping with an every-six weeks cadence.
Romain, you can always target Jiras to this release, and then the release
manager can decide on a case-by-case basis whether to make sure the fix is
included.
On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <ro...@google.com>
wrote:
> Yep. I am starting the "Let's do a 2.4.0 release" thread almost
> exactly 6 weeks after JB first started the 2.3.0 release thread.
>
> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
> > I would like to +1 the faster release cycle process JB and Robert have
> been
> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
> > When we block for specific features and increase the time between
> releases,
> > we increase the urgency for PR authors to push for their change to go
> into
> > an upcoming release, which is a feedback loop that results in our
> releases
> > taking months instead of weeks. We should however try to get pending PRs
> > wrapped up.
> >
> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >>
> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just out
> >> so 1 week is a bit fast IMHO.
> >>
> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a
> écrit :
> >>>
> >>> One of the main shifts that I think helped this release was explicitly
> >>> not being feature driven, rather releasing what's already in the
> >>> branch. That doesn't mean it's not a good call to action to try and
> >>> get long-pending PRs or similar wrapped up.
> >>>
> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
> >>> <rm...@gmail.com> wrote:
> >>> > There are a lot of long pending PR, would be good to merge them
> before
> >>> > 2.4.
> >>> > Some are bringing tests for the 2.3 release which can be critical to
> >>> > include.
> >>> >
> >>> > Maybe we should list the pr and jira we want it before picking a
> date?
> >>> >
> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <
> katsiapis@google.com>
> >>> > a
> >>> > écrit :
> >>> >>
> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6
> (and
> >>> >> the
> >>> >> latter already has an RC out, so we will likely be blocked on Beam).
> >>> >>
> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
> >>> >> <ro...@google.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
> >>> >>> made this happen!) It'd be great to keep the ball rolling for a
> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made
> the
> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based
> cut
> >>> >>> date early next week (say the 28th).
> >>> >>>
> >>> >>> I'll volunteer to do this release.
> >>> >>>
> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
> >>> >> 650-918-7487
>
Re: Beam 2.4.0
Posted by Robert Bradshaw <ro...@google.com>.
Yep. I am starting the "Let's do a 2.4.0 release" thread almost
exactly 6 weeks after JB first started the 2.3.0 release thread.
On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <cc...@google.com> wrote:
> I would like to +1 the faster release cycle process JB and Robert have been
> advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
> When we block for specific features and increase the time between releases,
> we increase the urgency for PR authors to push for their change to go into
> an upcoming release, which is a feedback loop that results in our releases
> taking months instead of weeks. We should however try to get pending PRs
> wrapped up.
>
> On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just out
>> so 1 week is a bit fast IMHO.
>>
>> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a écrit :
>>>
>>> One of the main shifts that I think helped this release was explicitly
>>> not being feature driven, rather releasing what's already in the
>>> branch. That doesn't mean it's not a good call to action to try and
>>> get long-pending PRs or similar wrapped up.
>>>
>>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>>> <rm...@gmail.com> wrote:
>>> > There are a lot of long pending PR, would be good to merge them before
>>> > 2.4.
>>> > Some are bringing tests for the 2.3 release which can be critical to
>>> > include.
>>> >
>>> > Maybe we should list the pr and jira we want it before picking a date?
>>> >
>>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <ka...@google.com>
>>> > a
>>> > écrit :
>>> >>
>>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6 (and
>>> >> the
>>> >> latter already has an RC out, so we will likely be blocked on Beam).
>>> >>
>>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw
>>> >> <ro...@google.com>
>>> >> wrote:
>>> >>>
>>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
>>> >>> made this happen!) It'd be great to keep the ball rolling for a
>>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made the
>>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based cut
>>> >>> date early next week (say the 28th).
>>> >>>
>>> >>> I'll volunteer to do this release.
>>> >>>
>>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>>> >> 650-918-7487
Re: Beam 2.4.0
Posted by Charles Chen <cc...@google.com>.
I would like to +1 the faster release cycle process JB and Robert have been
advocating and implementing, and thank JB for releasing 2.3.0 smoothly.
When we block for specific features and increase the time between releases,
we increase the urgency for PR authors to push for their change to go into
an upcoming release, which is a feedback loop that results in our releases
taking months instead of weeks. We should however try to get pending PRs
wrapped up.
On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just out
> so 1 week is a bit fast IMHO.
>
> Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a écrit :
>
>> One of the main shifts that I think helped this release was explicitly
>> not being feature driven, rather releasing what's already in the
>> branch. That doesn't mean it's not a good call to action to try and
>> get long-pending PRs or similar wrapped up.
>>
>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
>> <rm...@gmail.com> wrote:
>> > There are a lot of long pending PR, would be good to merge them before
>> 2.4.
>> > Some are bringing tests for the 2.3 release which can be critical to
>> > include.
>> >
>> > Maybe we should list the pr and jira we want it before picking a date?
>> >
>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <ka...@google.com>
>> a
>> > écrit :
>> >>
>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6 (and
>> the
>> >> latter already has an RC out, so we will likely be blocked on Beam).
>> >>
>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw <robertwb@google.com
>> >
>> >> wrote:
>> >>>
>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
>> >>> made this happen!) It'd be great to keep the ball rolling for a
>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made the
>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based cut
>> >>> date early next week (say the 28th).
>> >>>
>> >>> I'll volunteer to do this release.
>> >>>
>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Gus Katsiapis | Software Engineer | katsiapis@google.com |
>> 650-918-7487 <(650)%20918-7487>
>>
>
Re: Beam 2.4.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just out so
1 week is a bit fast IMHO.
Le 20 févr. 2018 23:13, "Robert Bradshaw" <ro...@google.com> a écrit :
> One of the main shifts that I think helped this release was explicitly
> not being feature driven, rather releasing what's already in the
> branch. That doesn't mean it's not a good call to action to try and
> get long-pending PRs or similar wrapped up.
>
> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > There are a lot of long pending PR, would be good to merge them before
> 2.4.
> > Some are bringing tests for the 2.3 release which can be critical to
> > include.
> >
> > Maybe we should list the pr and jira we want it before picking a date?
> >
> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <ka...@google.com>
> a
> > écrit :
> >>
> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6 (and
> the
> >> latter already has an RC out, so we will likely be blocked on Beam).
> >>
> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw <ro...@google.com>
> >> wrote:
> >>>
> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
> >>> made this happen!) It'd be great to keep the ball rolling for a
> >>> similarly well-executed 2.4. A lot has gone in [1] since we made the
> >>> 2.3 cut, and to keep our cadence up I would propose a time-based cut
> >>> date early next week (say the 28th).
> >>>
> >>> I'll volunteer to do this release.
> >>>
> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
> >>
> >>
> >>
> >>
> >> --
> >> Gus Katsiapis | Software Engineer | katsiapis@google.com | 650-918-7487
>
Re: Beam 2.4.0
Posted by Robert Bradshaw <ro...@google.com>.
One of the main shifts that I think helped this release was explicitly
not being feature driven, rather releasing what's already in the
branch. That doesn't mean it's not a good call to action to try and
get long-pending PRs or similar wrapped up.
On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> There are a lot of long pending PR, would be good to merge them before 2.4.
> Some are bringing tests for the 2.3 release which can be critical to
> include.
>
> Maybe we should list the pr and jira we want it before picking a date?
>
> Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <ka...@google.com> a
> écrit :
>>
>> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6 (and the
>> latter already has an RC out, so we will likely be blocked on Beam).
>>
>> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw <ro...@google.com>
>> wrote:
>>>
>>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
>>> made this happen!) It'd be great to keep the ball rolling for a
>>> similarly well-executed 2.4. A lot has gone in [1] since we made the
>>> 2.3 cut, and to keep our cadence up I would propose a time-based cut
>>> date early next week (say the 28th).
>>>
>>> I'll volunteer to do this release.
>>>
>>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>>
>>
>>
>>
>> --
>> Gus Katsiapis | Software Engineer | katsiapis@google.com | 650-918-7487
Re: Beam 2.4.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
There are a lot of long pending PR, would be good to merge them before 2.4.
Some are bringing tests for the 2.3 release which can be critical to
include.
Maybe we should list the pr and jira we want it before picking a date?
Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" <ka...@google.com> a
écrit :
> +1 since tf.transform <https://github.com/tensorflow/transform> 0.6
> depends on Beam 2.4 and Tensorflow 1.6 (and the latter already has an RC
> out, so we will likely be blocked on Beam).
>
> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw <ro...@google.com>
> wrote:
>
>> Now that Beam 2.3.0 went out (and in record time, kudos to all that
>> made this happen!) It'd be great to keep the ball rolling for a
>> similarly well-executed 2.4. A lot has gone in [1] since we made the
>> 2.3 cut, and to keep our cadence up I would propose a time-based cut
>> date early next week (say the 28th).
>>
>> I'll volunteer to do this release.
>>
>> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>>
>
>
>
> --
> Gus Katsiapis | Software Engineer | katsiapis@google.com | 650-918-7487
>
Re: Beam 2.4.0
Posted by Konstantinos Katsiapis <ka...@google.com>.
+1 since tf.transform <https://github.com/tensorflow/transform> 0.6 depends
on Beam 2.4 and Tensorflow 1.6 (and the latter already has an RC out, so we
will likely be blocked on Beam).
On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw <ro...@google.com>
wrote:
> Now that Beam 2.3.0 went out (and in record time, kudos to all that
> made this happen!) It'd be great to keep the ball rolling for a
> similarly well-executed 2.4. A lot has gone in [1] since we made the
> 2.3 cut, and to keep our cadence up I would propose a time-based cut
> date early next week (say the 28th).
>
> I'll volunteer to do this release.
>
> [1] https://github.com/apache/beam/compare/release-2.3.0...master
>
--
Gus Katsiapis | Software Engineer | katsiapis@google.com | 650-918-7487