Greetings. Here’s a quick look at Cassandra 4.0 release status for the
week. Eight days since the last report.
Jira board with 4.0 scope:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
High level numbers by release phase:
Beta: 15 (-7); 10 in-flight; A good
Hi Cassandra Dev team,
I was using Cassandra's bulk loading tool on a simple auth based setup. I
found out that we need to pass *"-u and -pw" *parameters on Auth enabled
Casandra setup. If I use the command using these parameters then if someone
(any user with login access to Cassandra host machin
Python 2 was EOLed over a year ago. I think it's fine to (1) require
python 3 to run cqlsh and (2) remove code that supports python 2 whenever
it's convenient.
Angelo has the right idea that rather than trying to finesse a deprecation
cycle into 4.0 at this late date, a better migration path can
On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg
wrote:
> I want to emphasize here: to my way of thinking, "dropping support" at this
> juncture is just a matter of documenting it, and maybe introducing a
> warning. We don't need to *remove* support for python2. It will continue to
> work as-is. Thi
>
> Does anybody know what are the practicalities/hurdles
> that users can face when upgrading and what is the expected cost of keeping
> support for 2.7 until the next major?
>
Given that the code supports both, the only barrier to the user is "does my
distro have python3 (most likely), or would
I understood us to have agreed to drop semver, because our major/minor history
has been a meaningless distinction, and instead to go major/patch (or
major/minor - with minor for patches), depending how you want to slice it.
But there have been a lot of discussions over the past year or so, so I
>
> My preference is for a simple annual major release cadence, with minors as
> necessary.
>
I do not think that I fully understand your proposal. How do you define a
major and a minor release?
My understanding of a major release was a version that broke some of the
compatibilities. By consequenc
Perhaps we could also consider quarterly "develop" releases, so that we have
pressure to maintain a shippable trunk? This provides some opportunity for more
releases without incurring the project maintenance costs or user coordination
costs. Something like a feature-incomplete mid-cycle RC, that
