There were no new updates, I will start a vote based on the latest proposal.
On Mon, Nov 5, 2018 at 10:19 AM, Ahmet Altay wrote:
> +1 to starting with 2.7 branch and supporting it for 6 months. I think we
> should start the support window of 6 months from the day we agree to do
> this. That way
+1 to starting with 2.7 branch and supporting it for 6 months. I think we
should start the support window of 6 months from the day we agree to do
this. That way users will at least get the benefit for 6 months after
learning about LTS status.
It seems like there is a consensus. Should we hold a
Yes, cutting more patch releases is the goal of the LTS release. We
have not yet determined what the threshold is for backporting bugfixes
(which, in part, depends on how much work that is) nor how often we'd
do a release.
On Mon, Nov 5, 2018 at 3:42 PM Chamikara Jayalath wrote:
>
> +1 for using
The result shows that there is a demand for an LTS release.
+1 for using an existing release. How about six months for the initial
LTS release? I think it shouldn't be too long for the first one to give
us a chance to make changes to the model.
-Max
On 02.11.18 17:26, Ahmet Altay wrote:
Twitter vote concluded with 52 votes with the following results:
- 52% Stable LTS releases
- 46% Upgrade to latest release
- 2% Keep using older releases
This reads like another supporting evidence for making LTS releases. In the
light of this, what do you all think about Kenn's proposal of
On Tue, Oct 23, 2018 at 3:03 PM, Kenneth Knowles wrote:
> Yes, user@ cannot reach new users, really. Twitter might, if we have
> enough of adjacent followers to get it in front of the right people. On the
> other hand, I find testimonials from experience convincing in this case.
>
I agree I am
Yes, user@ cannot reach new users, really. Twitter might, if we have enough
of adjacent followers to get it in front of the right people. On the other
hand, I find testimonials from experience convincing in this case.
Kenn
On Tue, Oct 23, 2018 at 2:59 PM Ahmet Altay wrote:
>
>
> On Tue, Oct
On Tue, Oct 23, 2018 at 9:16 AM, Thomas Weise wrote:
>
>
> On Mon, Oct 22, 2018 at 2:42 PM Ahmet Altay wrote:
>
>> We attempted to collect feedback on the mailing lists but did not get
>> much input. From my experience (mostly based on dataflow) there is a
>> sizeable group of users who are
On Mon, Oct 22, 2018 at 2:11 AM, Robert Bradshaw
wrote:
> On Sat, Oct 20, 2018 at 12:24 AM Kenneth Knowles wrote:
>
>> Pinging this. I think Beam should have a live LTS branch.
>>
>> I want to suggest a different approach: choose something already released
>> to be LTS. This way it has had some
On Sat, Oct 20, 2018 at 12:24 AM Kenneth Knowles wrote:
> Pinging this. I think Beam should have a live LTS branch.
>
> I want to suggest a different approach: choose something already released
> to be LTS. This way it has had some usage and we have some confidence there
> are no critical
Pinging this. I think Beam should have a live LTS branch.
I want to suggest a different approach: choose something already released
to be LTS. This way it has had some usage and we have some confidence there
are no critical problems.
So how about we make 2.7 the first LTS branch?
Kenn
On Wed,
Update: I re-cut the release branch. Only remaining issue on the 2.8.0 list
is currently RabbitMQIO. JB, let me know if you would like to cherry pick
that in to the release branch.
On Wed, Oct 10, 2018 at 1:44 PM, Ahmet Altay wrote:
> Given the number of open issues, I will re-cut the release
Given the number of open issues, I will re-cut the release branch once the
blocking issues are resolved. Don't worry about cherry picking changes to
directly to the release branch for now.
I will continue to update this thread.
On Wed, Oct 10, 2018 at 12:12 PM, Niel Markwick wrote:
> The 3
Thank you JB.
It turns out there are 2 more blocker issues. I will look at them now
first. (So, I am not rushing towards cutting RC1 yet.)
On Wed, Oct 10, 2018 at 11:42 AM, Jean-Baptiste Onofré
wrote:
> Hey
>
> Etienne should do a new pass soon. I do my best to cherry pick RabbitMQIO.
>
>
Hey
Etienne should do a new pass soon. I do my best to cherry pick RabbitMQIO.
Thanks
Regards
JB
Le 10 oct. 2018 à 21:25, à 21:25, Ahmet Altay a écrit:
>Update:
>
>I started cutting the branch. There are 2 open issues:
>- RabbitMQIO - JB, if you plan to complete this soon I can cherry pick
>to
Update:
I started cutting the branch. There are 2 open issues:
- RabbitMQIO - JB, if you plan to complete this soon I can cherry pick to
the branch.
- One new issue related to release process changes with respect to
beam-site deprecation.
On Tue, Oct 9, 2018 at 11:38 AM, Jean-Baptiste Onofré
some times Ago JB spoke about Beam roadmap. I tend to think this discussion
does no make any sense without a clear roadmap. The rational here is that a
roadmap will give you the future changes
and the potential future versions (we spoke a few times of Beam 3). This
does not have to be very
On Wed, Oct 10, 2018 at 2:56 AM Robert Bradshaw wrote:
> On Wed, Oct 10, 2018 at 9:37 AM Ismaël Mejía wrote:
>
>> The simplest thing we can do is just to pin all the deps of the LTS
>> and not move them in any maintenance release if not a strong reason to
>> do so.
>>
>> The next subject is to
On Wed, Oct 10, 2018 at 9:37 AM Ismaël Mejía wrote:
> The simplest thing we can do is just to pin all the deps of the LTS
> and not move them in any maintenance release if not a strong reason to
> do so.
>
> The next subject is to make maintainers aware of which release will be
> the LTS in
The simplest thing we can do is just to pin all the deps of the LTS
and not move them in any maintenance release if not a strong reason to
do so.
The next subject is to make maintainers aware of which release will be
the LTS in advance so they decide what to do with the dependencies
versions. In
I've seen two mentions that "rushing" is contrary to the goals of LTS. But
I wouldn't worry about this. The fact is there is almost nothing you can do
to stabilize ***prior*** to cutting the LTS branch. Stability comes from
the branch being long-lived and having multiple releases.
(I think this
On Fri, Oct 5, 2018 at 4:38 AM, Jean-Baptiste Onofré
wrote:
> Hi,
>
> I think we have to remember what it's a LTS. A LTS is clearly a branch
> that we guarantee to have fixes on it for a long period of time.
> It doesn't mean that LTS == unique release. We can do a bunch of
> releases on a LTS
Ok. Gonna move forward on RabbitMQIO asap.
Thanks
Regards
JB
Le 9 oct. 2018 à 21:00, à 21:00, Ahmet Altay a écrit:
>Hi all,
>
>Reminder, I will cut the release branch tomorrow. If you have not done
>so
>please take a look at the 2.8.0 issues assigned to you [1].
>
>Thank you!
>Ahmet
>
>[1]
Hi all,
Reminder, I will cut the release branch tomorrow. If you have not done so
please take a look at the 2.8.0 issues assigned to you [1].
Thank you!
Ahmet
[1]
Hi,
I think we have to remember what it's a LTS. A LTS is clearly a branch
that we guarantee to have fixes on it for a long period of time.
It doesn't mean that LTS == unique release. We can do a bunch of
releases on a LTS branch, the only constraint is to avoid to introduce
breaking changes.
On Fri, Oct 5, 2018 at 3:59 AM Chamikara Jayalath
wrote:
>
> On Thu, Oct 4, 2018 at 9:39 AM Ahmet Altay wrote:
>
>> I agree that LTS releases require more thought. Thank you for raising
>> these questions. What other open questions do we have related LTS releases?
>>
>> One way to do this would
On Thu, Oct 4, 2018 at 9:39 AM Ahmet Altay wrote:
> I agree that LTS releases require more thought. Thank you for raising
> these questions. What other open questions do we have related LTS releases?
>
> One way to do this would be to add them to a particular tracking list
> (e.g. 2.9.0 blocking
I agree that LTS releases require more thought. Thank you for raising these
questions. What other open questions do we have related LTS releases?
One way to do this would be to add them to a particular tracking list (e.g.
2.9.0 blocking list) that way we would be ready for an LTS release ahead of
Thank you all for the feedback. I will continue with 2.8.0 as a regular
release and separate the LTS discussion to a new thread.
On Thu, Oct 4, 2018 at 7:58 AM, Thomas Weise wrote:
> Given the feedback so far, we should probably decouple LTS and 2.8.0
> discussions. In case both converge before
Given the feedback so far, we should probably decouple LTS and 2.8.0
discussions. In case both converge before 10/10 then fine, but not
necessary. I also agree that we should not jump the gun on LTS and minimum
72 hours feedback window for the topic looks appropriate.
The issues raised by Tim
As for the outstanding issues: We have "Fix Version" in JIRA. Everything
not marked as CRITICAL or BLOCKER should just be moved to the next
version. That can easily be done in bulk.
Considering not much time is left until the release, I don't think an
LTS makes sense this time. Thanks for
Regarding LTS release - I agree that we need to have clear view what kind of
support will be provided for such releases.
Despite of the concerns mentioned before, I have another one about API labeled
as “@Experimental". I think there are most of IOs, SQL, PCollection with
Schema, etc, labeled
+1 to cutting the release.
I agree that the LTS label requires more discussion. I think it boils down
to the question of whether we are comfortable with encouraging people to
not upgrade to the latest Beam. It probably boils down to creating a list
of (potential) blockers and then going from
I was in the middle of writing something similar when Ismaël posted.
Please do bear in mind that this is an international project and 7hrs is
not long enough to decide upon something that affects us all.
+1 on cutting 2.8.0 on 10/10 and thank you for pushing it forward
-1 on designating it as
Hello,
Thanks Ahmet for volunteering to do the release, and proposing this as an LTS.
I have still some questions on our LTS policies (which may have
consequences on the discussed release):
What are the expected implications of upgrades in the LTS, e.g. If a
connector let’s say Kafka is
Great. I will do the cut on 10/10.
Let's start by triaging the open issues targeted for 2.8.0 [1]. If you have
any issues in this list please resolve them or move to the next release. If
you are aware of any critical issues please add to this list.
Ahmet
[1]
+1
On Wed, Oct 3, 2018 at 12:33 PM Ted Yu wrote:
> +1
>
> On Wed, Oct 3, 2018 at 9:52 AM Jean-Baptiste Onofré
> wrote:
>
>> +1
>>
>> but we have to be fast in release process. 2.7.0 took more than 1 month
>> to be cut !
>>
>> If no blocker, we have to just move forward.
>>
>> Regards
>> JB
>>
+1 for the 2.7.0 release schedule. Thanks for volunteering. Do we want a
standing owner for the LTS branch (like the Linux kernel has) or will we
just take volunteers for each LTS release as they arise?
Andrew
On Wed, Oct 3, 2018 at 12:33 PM Ted Yu wrote:
> +1
>
> On Wed, Oct 3, 2018 at 9:52
+1
On Wed, Oct 3, 2018 at 9:52 AM Jean-Baptiste Onofré wrote:
> +1
>
> but we have to be fast in release process. 2.7.0 took more than 1 month
> to be cut !
>
> If no blocker, we have to just move forward.
>
> Regards
> JB
>
> On 03/10/2018 18:25, Ahmet Altay wrote:
> > Hi all,
> >
> > Release
+1
but we have to be fast in release process. 2.7.0 took more than 1 month
to be cut !
If no blocker, we have to just move forward.
Regards
JB
On 03/10/2018 18:25, Ahmet Altay wrote:
> Hi all,
>
> Release cut date for the next release is 10/10 according to Beam release
> calendar [1]. Since
Hi all,
Release cut date for the next release is 10/10 according to Beam release
calendar [1]. Since the previous release is already mostly wrapped up
(modulo blog post), I would like to propose starting the next release on
time (10/10).
Additionally I propose designating this release as the
41 matches
Mail list logo
