Re: Rough roadmap for 4.0

It's not marked fixed, it's marked resolved and the resolution is duplicate. This is how all dupes are marked in jira. On Fri, Nov 18, 2016 at 2:30 PM, Edward Capriolo wrote: > These tickets claim to duplicate each other: > >

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

On 18 November 2016 at 18:25, Jason Brown wrote: > #11559 (enhanced node representation) - decided it's *not* something we > need wrt #7544 storage port configurable per node, so we are punting on > #12344 - Forward writes to replacement node with same address during

Cassandra Mutation object decoding

Hi there, I am trying to read the Commit logs to decode the original CQL which used. I get to the point an implemention of CommitLogReadHandler is able to push back Mutation objects from the Commit logs. Questions: 1) CQL: delete from myks.mytable where key1 = 1; For the above CQL, the

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

Introducing all of these in a single release seems pretty risky. I think it would be safer to spread these out over a few 4.x releases (as they’re finished) and give them time to stabilize before including them in an LTS release. The downside would be having to maintain backwards compatibility

Re: Rough roadmap for 4.0

These tickets claim to duplicate each other: https://issues.apache.org/jira/browse/CASSANDRA-12674 https://issues.apache.org/jira/browse/CASSANDRA-12746 But one is marked fixed and the other is still open. What is the status here? On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

Hi Nate, Most of the JIRAs in the middle are being rebased or being reviewed and code is already out there. These will make 4.0 a very solid release. Thanks, Sankalp On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead wrote: > We are happy to start testing against

[VOTE] Release Apache Cassandra 3.10 (Take 3)

I propose the following artifacts for release as 3.10. sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative Artifacts:

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

+1 On 2016-11-18 10:08 (-0800), Michael Shuler wrote: > I propose the following artifacts for release as 3.10. > > sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative >

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

We should assume that we’re ditching tick/tock. I’ll post a thread on 4.0-and-beyond here in a few minutes. The advantage of a prod release every 6 months is fewer incentive to push unfinished work into a release. The disadvantage of a prod release every 6 months is then we either have a very

Proposals for releases - 4.0 and beyond

With 3.10 voting in progress (take 3), 3.11 in December/January (probably?), we should solidify the plan for 4.0. I went through the archives and found a number of proposals. We (PMC) also had a very brief chat in private to make sure we hadn’t missed any, and here are the proposals that we’ve

Re: Proposals for releases - 4.0 and beyond

I think the monthly releases are important, otherwise releases become an “event”. The monthly releases mean they are just a normal thing that happens. So I like any of 3/4/5. Sylvain's proposal sounds interesting to me. My only concern would be with making sure we label things very clearly

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

+1 On Fri, Nov 18, 2016 at 12:08 PM, Michael Shuler wrote: > I propose the following artifacts for release as 3.10. > > sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.10-tentative

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

> While stability is important if we push back large "core" changes until later > we're just setting ourselves up to face the same issues later on In theory, yes. In practice, when incomplete features are earmarked for a certain release, those features are often rushed out, and not always fully

Re: Proposals for releases - 4.0 and beyond

Option 3 seems the most reasonable and the clearest from a user perspective. The main thing I'd be concerned about with a 6 month cycle would be how short a branch is supported for. Most users will be bound to a specific release for at least 2 years, and we still find bugs in 2.1 2 years since