Github user spodkowinski commented on the issue:
https://github.com/apache/cassandra/pull/74
Looks like this has already been fixed in
c7f6ba8a42944338ec3e7d6793383b5537dfd82a
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as w
I have investigated the problem and found that monitoring was serriously
changed since 3.7(version when I got exception in
com.codahale.metrics.servlets.MetricsServlet). Since version 3.9 it is enough
to change behavior of DecayingEstimatedHistogramReservoir, the
EstimatedHistogram should stay
Is there consensus on a way forward with this? Is there going to be a three
branch plan with “features”, “testing”, and “stable” starting with 4.0? Or is
this still in the discussion mode? External to this thread there have been
decisions made to create third party LTS releases and hopes that
For reference we have released https://github.com/instaclustr/cassandra ,
with the end goal that people have a stable target on the 3.x branch while
this is all worked out.
We are likely to continue our releases even with a release cadence change,
but we would track official versions much more clo
Thanks Ben. It’s great to have a 3.x LTS option as things work themselves out.
I just wanted to revive this thread in parallel so that it could hopefully
come to a way forward for the project as well. Is the 3 branch strategy that
Sylvain proposed the way forward?
> On Oct 20, 2016, at 11:52
If you think of the tick tock releases as interim development releases I
actually think they have been working pretty well. What if we continue with the
same process and do 4.0.x as LTS like we have 3.0.x LTS.
So you get 4.x releases that are trickling out new features which will
eventually be
Open a new issue and link to CASSANDRA-11063. Including a test case
addressing your issue that fails after the 11063 change would be ideal
as well.
Either way, thanks for the continued attention on this.
On Fri, Oct 21, 2016 at 4:06 AM, Владимир Бухтояров
wrote:
> I have investigated the problem
On 2016-10-20 13:26 (-0700), "J. D. Jordan" wrote:
> If you think of the tick tock releases as interim development releases I
> actually think they have been working pretty well. What if we continue with
> the same process and do 4.0.x as LTS like we have 3.0.x LTS.
>
> So you get 4.x releas
i think this is already fixed in
https://issues.apache.org/jira/browse/CASSANDRA-7
On Thu, Oct 20, 2016 at 3:56 PM, Nate McCall wrote:
> Open a new issue and link to CASSANDRA-11063. Including a test case
> addressing your issue that fails after the 11063 change would be ideal
> as well.
>
>
Hi,
We backport a lot of patches in Cassandra at Apple. We contribute all
the patches to the community and port them to 2.1 if we think they will
help. We will soon start focusing on 3.0 and won't back port to 2.1 unless
critical.
I want to list them in this email in random order and not base
In the original tick tock plan we would not have kept 4.0.x around. So I am
proposing a change for that and then we label the 3.x and 4.x releases as
"development releases" or some other thing and have "yearly" LTS releases with
.0.x.
Those are similar to the previous 1.2/2.0/2.1/2.2 and we are
On 2016-10-20 14:21 (-0700), Jeremiah Jordan wrote:
> In the original tick tock plan we would not have kept 4.0.x around. So I am
> proposing a change for that and then we label the 3.x and 4.x releases as
> "development releases" or some other thing and have "yearly" LTS releases
> with .0
My thinking was we keep doing tick/tock for the 4.x. Basically continue on for
4.0.x / 4.x like we have been with 3.0.x / 3.x, just with some added guidance
to people that 4.x is “development releases”. The main problem I hear with the
tick tock stuff is that we won’t ever have “LTS” branches
I’m not sure it makes sense to have separate features/stability releases in
that world. 4.0.x will be stable, every 4.x will be a dev release on the road
to 5.0.
--
AY
On 20 October 2016 at 22:43:19, Jeff Jirsa (jji...@apache.org) wrote:
On 2016-10-20 14:21 (-0700), Jeremiah Jordan wrote:
> I’m not sure it makes sense to have separate features/stability releases in
> that world. 4.0.x will be stable, every 4.x will be a dev release on the road
> to 5.0.
>
+1. Much easier to understand and it's 'backwards compatible' (sort
of) with wherever we leave 3.x.
Still keeping 4.x on month
And +1 to ditching the "tick tock" alternating release thing nobody
understands it anyway.
On Thu, Oct 20, 2016 at 3:38 PM Jonathan Haddad wrote:
> From a community perspective a supported release every 6 months would be
> much more attractive than yearly, as having to wait ~9-10 months for
> so
>From a community perspective a supported release every 6 months would be
much more attractive than yearly, as having to wait ~9-10 months for
something like SASI is kind of frustrating.
Monthly dev releases is awesome.
On Thu, Oct 20, 2016 at 3:18 PM Nate McCall wrote:
> > I’m not sure it make
this is awesome
On Thu, 20 Oct 2016 at 14:19 sankalp kohli wrote:
> Hi,
> We backport a lot of patches in Cassandra at Apple. We contribute all
> the patches to the community and port them to 2.1 if we think they will
> help. We will soon start focusing on 3.0 and won't back port to 2.1 unl
18 matches
Mail list logo
