Github user mmajercik closed the pull request at:
https://github.com/apache/cassandra/pull/84
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
On 4 November 2016 at 13:47, Nate McCall wrote:
> Specifically, this should be "new stuff that could/will break things"
> given we are upping
> the major version.
>
How does this co-ordinate with the tick-tock versioning¹ leading up to the
4.0 release?
To just stop tick-tock and then say yeeha
I’ll comment on the broader issue, but right now I want to elaborate on
3.11/January/arbitrary cutoff date.
Doesn’t matter what the original plan was. We should continue with 3.X until
all the 4.0 blockers have been
committed - and there are quite a few of them remaining yet.
So given all the h
On 16 November 2016 at 11:45, Aleksey Yeschenko
wrote:
>
> Doesn’t matter what the original plan was. We should continue with 3.X
> until all the 4.0 blockers have been
> committed - and there are quite a few of them remaining yet.
Thanks for the clarity, the quick reply I was hoping for :-)
Agreed. As long as we have a goal I don't see why we have to adhere to
arbitrary date for 4.0.
On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" wrote:
> I’ll comment on the broader issue, but right now I want to elaborate on
> 3.11/January/arbitrary cutoff date.
>
> Doesn’t matter what the original
Hi,
I think one additional issue to add to the pile is CASSANDRA-7544 "Allow
storage port to be configurable per node"
I think no matter what we land on implementation wise it will only
possible to make this change in a major release as it will means change
to the system schema as well as interno
