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,
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
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
20 matches
Mail list logo
