David,
I think we're getting a bit off-topic now, but it seems we already
have a consensus on the main question. You're right about column
descriptions, adding new columns to vtables, and moving fields
description from yaml to the source code - all that will be part of
other changes anyway, so let
Hi everyone,
Some updates and questions around JDK 17 below.
First of all, I wanted to let people know that currently Cassandra trunk
can be already compiled and run with J8 + J11 + J17. This is the product of
the realization that the feature branch makes it harder for working on
JDK17 related tick
Link to the next episode:
https://drive.google.com/file/d/1nvHs7o4JJC2P18mtR5MrbnNoeW5f44j1/view?usp=sharing
s2Ep1 - Patrick McFadin
(You may have to download it to listen)
It will remain in staging for 72 hours, going live (assuming no objections)
by Saturday, March 4th (19:00 UTC).
If anyone
I am cool with defining target release date and working backwards from there.
If we do want to go this route, I think we do need to answer why 4.1 cut ->
release took so much time, and if people could start validation “before” we
branch? If we know trunk is stable today then we could release t
> Another option would be to introduce a second class with the same fields as
> the first where we simply specify final for immutable fields, and construct
> it after parsing the Config.
>
> We could even generate the non-final version from the one with final fields.
>
> Not sure this would be
We have been talking a lot about the branch cutting date, but I agree with Benedict here, I think we should actually be talking about the expected release date. If we truly believe that we can release within 1-2 months of cutting the branch, and many people I have talked to think that is possible,
Hi
Those are great questions Mick. It's good to recognize this discussion
impacts a broad range of contributors and users, and not all of them might
be aware of the discussion in the first place.
More generally I would say that your questions brought to mind two
fundamental principles with a "tra
Thank you all for your replies. Let me add some comments too,
>From a public API perspective, we have three types of fields in the
Config class: internal use only (e.g. logger, PROPERTY_PREFIX prefix),
read-only use (e.g. cluster_name), and read-write fields that are
currently mutated with JMX. S
In the interest of broadening perspectives, thoughts here from two angles:
community engagement and marketing. We will be discussing what’s coming in
Cassandra 5.0 at Cassandra Forward in 2 weeks. This is meant to build
excitement for the next version so having technology for folks to get thei
It doesn’t look like we agreed to a policy of annual branch dates, only annual
releases and that we would schedule this for 4.1 based on 4.0’s branch date.
Given this was the reasoning proposed I can see why folk would expect this
would happen for the next release. I don’t think there was a stro
>
> My thoughts don't touch on CEPs inflight.
>
For the sake of broadening the discussion, additional questions I think
worthwhile to raise are…
1. What third parties, or other initiatives, are invested and/or working
against the May deadline? and what are their views on changing it?
1a. If w
I am fine with annotations. I am not a big of fan of the generation. From my
experience whenever we wanted to generate something we had to take care of the
generator itself and then we had to live with what it generated (yeah, that is
also a thing) instead of writing it by hand once and have som
Another option would be to introduce a second class with the same fields as the first where we simply specify final for immutable fields, and construct it after parsing the Config.We could even generate the non-final version from the one with final fields.Not sure this would be nicer, but it is an
13 matches
Mail list logo
