[RESULT][VOTE] Simplifying our release versioning process

just bad at search). > > I do agree version and feature support is perhaps a separate topic from > killing the minor (which seems unambiguously good). > > -Joey > > > On Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie wrote: >> __ >> Pragmatically, I believe

Re: [VOTE] Simplifying our release versioning process

Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had: - Release 21.0.0: JDK30, JDK31 - Release 22.0.0: JDK35, JDK40 We wouldn't be able to t

Re: [VOTE] Simplifying our release versioning process

>>> +1 >>>>> >>>>> On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova >>>>> wrote: >>>>>> +1 >>>>>> >>>>>> I also remember we agreed on Discuss thread for removing anything plus >>&g

Re: [DISCUSS] How we version our releases

> But once we decide there’s good reason to, I don’t think arbitrary lifetimes > for a feature are really all that helpful are they? > > > > > >> On 18 Apr 2025, at 20:03, Josh McKenzie wrote: >>  >>> I personally feel that patch level fixes

Re: [DISCUSS] How we version our releases

s > what matters, everything after is after that point and falls into (N + 1).0.0 > > We can also say that deprecation is frozen in N.0.0 and can only happen on > trunk… no back ports allowed… both my recommendation and “no back ports” have > the same effect. > >> On Apr 18

Re: [VOTE] Simplifying our release versioning process

high bar for user API-breaking changes – much higher than "our rules > allow us to". Any time we break users, the project loses release uptake and > creates friction for the community. > > – Scott > >> On Apr 17, 2025, at 2:32 PM, Nate McCall wrote: >> >

Re: [DISCUSS] How we version our releases

le), >> and then finally make the breaking change in N + 1? >> >> Similarly, for a released version, say M (where trunk is at N), should the >> author patch M to mark the feature as deprecated, and wait until N is >> released (deprecating for one major release cycle

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > 1. We no longer use semver .MINOR > 2. Online upgrades are supported for all GA sup

[VOTE] Simplifying our release versioning process

[DISCUSS] thread: https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq The proposed new versioning mechanism: 1. We no longer use semver .MINOR 2. Online upgrades are supported for all GA supported releases at time of new .MAJOR 3. T-1 releases are guaranteed API compatible for no

Re: [DISCUSS] How we version our releases

ill leave this thread for another 24 hours to see if there's any other concerns and call a vote if not. Thanks everyone for the engagement. On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote: >> So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to >

Re: Constraint's "not null" alignment with transactions and their simplification

gt; >>> >>> If we have a goal of eventually providing ANSI SQL support one day, we >>> should at least stick to the ANSI SQL standard where applicable for >>> features in the meantime. AFAICT the reason everyone else does this the >>> same is i

Re: Project hygiene on old PRs

;>> a script every few weeks. Funny that people don't forget to create a >>>>>>>> PR when trying to make a change but as soon as it is delivered the >>>>>>>> respective PR is "memory holed". A PR does not close itself if it was

Re: Project hygiene on old PRs

> Funny that people don't forget to create a PR when trying to make a change > but as soon as it is delivered the respective PR is "memory holed". We use the PR mechanisms for review but don't use the PR mechanism for merge. Makes sense that we open them since they're part of our workflow and for

Re: Constraint's "not null" alignment with transactions and their simplification

Consistency *within* our own ecosystem supersedes consistency with other familiar ecosystems IMO. I'd prefer we consistently apply the CHECK keyword and don't have special cases that omit it, or perhaps have those as optional syntactic sugar but at its base the syntax is uniform and consistent.

Re: [DISCUSS] 5.1 should be 6.0

>>>>> >>>>>> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna >>>>>> wrote: >>>>>>  +1 for 6.0 for TCM/Accord changes, making it easier to make a case to >>>>>> upgrade dependencies like the Java/Python versions. >>&

Re: [DISCUSS] How we version our releases

ore wondering what the next version number will be. >> No more wondering what version I can upgrade from to use the new release. >> >> -Jeremiah >> >> On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie wrote: >>> >>> This came up in the thread from Jon on

Re: Project hygiene on old PRs

+1 from me. My intuition is that this is a logical consequence of us not using github to merge PR's so they don't auto-close. Which seems like it's a logical consequence of us using merge commits instead of per-branch commits of patches. The band-aid of at least having a human-in-the-loop to cl

[DISCUSS] How we version our releases

This came up in the thread from Jon on "5.1 should be 6.0". I think it's important that our release versioning is clear and simple. The current status quo of: - Any .MINOR to next MAJOR is supported - Any .MAJOR to next MAJOR is supported - We reserve .MAJOR for API breaking changes - exc

Re: [DISCUSS] 5.1 should be 6.0

Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated [DISCUSS] thread for my proposal above hopefully tomorrow, schedule permitting. On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote: > +1 to 6.0 > > On Thu, Apr 10, 2025 at 1:38 PM Josh McKe

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0. On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote: > Bringing this back up. > > I don't think we have any reason to hold up renaming the version. We can > have a separate discussion about what upgrade paths are supported, but let's > at least address this one issue of version numbe

Re: [DISCUSS] slack notifications for subprojects

ndra-dev and #cassandra-sidecar > > > 2) all other notifications to #cassandra-noise > > > WDYT? > > > > > > On Tue, 8 Apr 2025 at 15:48, Josh McKenzie wrote: > > > > > >> Currently we don't have Qbot notifying us on CASSSIDECAR ticke

[DISCUSS] slack notifications for subprojects

Currently we don't have Qbot notifying us on CASSSIDECAR ticket creation and state change. Seems we could: 1. notify in #cassandra-dev and #cassandra-sidecar 2. notify in the #cassandra-sidecar channel My preference is for 1 since there's a tight relationship between what we're doing with the s

Re: Huge NetApp donation of hardware for ci-cassandra

Thanks so much to NetApp and everyone who made this happen. This will be a hugely impactful donation! On Thu, Mar 20, 2025, at 7:26 AM, Maxim Muzafarov wrote: > This is extremely useful, I am the one who completely relies on the > ci-cassandra ;-) > Thank you! > > On Thu, 20 Mar 2025 at 11:52, J

Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

+1 On Tue, Mar 18, 2025, at 11:48 AM, C. Scott Andreas wrote: > +1 > >> On Mar 18, 2025, at 7:46 AM, Paulo Motta wrote: >> >> >> . >>> PMC members, please check carefully the IP Clearance requirements before >>> voting. >>> >>> The vote will be open for 72 hours (or longer). Votes by PMC mem

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

gt; >>> > In particular if latency stats are reported higher post-upgrade, we >>> > should expect users to interpret this as a performance regression, >>> > dedicating significant resources to investigating the change, and >>> > expending credibili

Re: Cassandra Java Driver and OpenJDK CRaC

Thanks for reaching out to the list Radim; this is interesting stuff. >From skimming the PR on the Spring side and the conversation there, it looks >like the argument is to have this live inside the java driver for Cassandra >instead of in the spring-boot lib which I can see the argument for. I

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

+1 On Sun, Mar 9, 2025, at 8:01 PM, Blake Eggleston wrote: > +1 > > On Sun, Mar 9, 2025, at 5:17 AM, Mick Semb Wever wrote: >> Please vote on the acceptance of the Cassandra Cluster Manager (CCM) >> and its IP Clearance: >> https://incubator.apache.org/ip-clearance/cassandra-ccm.html >> >> All c

March 2025 project status update

What happened last month? *New PMC members and committers, that's what.* We welcomed *three* new people to the PMC in Feb: Jeremiah Jordan, Caleb Rackliffe, and Ekaterina Dimitrova. We're the better for all three of them being here with us; thank you all for your hard work over the years and de

Re: March 2025 project status update

Did you know I sometimes fail at email filtering? 4 new committers! FOUR. Welcome to Bernardo Botella Corbi as well! That was 3 days ago too. /sigh Congrats everyone! On Fri, Mar 7, 2025, at 1:39 PM, Josh McKenzie wrote: > What happened last month? *New PMC members and committers, that

Re: CEP-15 Update

3.5 years is an incredible amount of time and work; it really is significant and thanks to everyone involved for the investment of time and energy. We have a rocky history with large, disruptive contributions in the past that have either blocked forward progress post-merge (CASSANDRA-8099), or l

Re: [DISCUSS] Plugins and dependencies

> I've gotten the impression that there's not a lot of enthusiasm for breaking > apart the main Cassandra module, but I have wondered if it'd be worth making > an exception for the interfaces plugins are supposed to code against Oh, there's *plenty* of enthusiasm. There's been a shortage of conse

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

> if the plan is to rip out something old and unmaintained and replace with > something new, I think there's a huge win to be had by implementing the > standard that everyone's using now. Strong +1 on anything that's an ecosystem integration inflection point. The added benefit here is that if we

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Welcome Ekaterina! \o/ On Tue, Mar 4, 2025, at 7:07 PM, Francisco Guerrero wrote: > Congratulations Ekaterina! Well deserved! > > On 2025/03/04 20:25:08 Paulo Motta wrote: > > Aloha, > > > > The Project Management Committee (PMC) for Apache Cassandra is delighted to > > announce that Ekaterina

Re: Welcome Bernardo Botella as Cassandra Committer

Congrats Bernardo - it's been great collaborating with you thus far and looking forward to more! On Tue, Mar 4, 2025, at 4:13 AM, Paulo Motta wrote: > ¡Felicitaciones Bernardo! Well deserved! > > Cheers, > > Paulo > > On Tue, 4 Mar 2025 at 06:10 Soheil Rahsaz wrote: >> Congrats, Bernardo! Wel

Re: Welcome Aaron Ploetz as Cassandra Committer

Congrats Aaron! On Tue, Mar 4, 2025, at 4:08 AM, Soheil Rahsaz wrote: > Congratulations Aaron! > > On Tue, Mar 4, 2025 at 12:09 PM Paulo Motta wrote: >> Congratulations Aaron, happy to see you recognized as a committer! >> >> Cheers, >> >> Paulo >> >> On Tue, 4 Mar 2025 at 03:26 Bernardo Bote

Re: [VOTE] Release Apache Sidecar Cassandra 0.1.0

+1 - great work everyone! On Fri, Feb 28, 2025, at 1:58 PM, Dinesh Joshi wrote: > +1, thanks to everyone who worked towards this milestone. > > On Fri, Feb 28, 2025 at 10:47 AM Doug Rohrer wrote: >> +1 (nb) >> >> Thanks for putting in the work to get this ready to go! >> >> Doug >> >> > On Fe

Re: Fix versions for CASSANDRA-19596 improve IntervalTree build throughput

This is a significant enough performance problem *in normal operations* I'd consider it a bug and thus eligible for back-porting. A couple other thoughts: > CASSANDRA-20158 and CASSANDRA-20164 are several orders of magnitudes faster > ... The only problem with this approach is that the tree is n

Re: Welcome Caleb Rackliffe to the PMC

Congratulations Caleb! On Fri, Feb 21, 2025, at 10:02 AM, Jacek Lewandowski wrote: > Congratulations Caleb!!! > > > - - -- --- - - > Jacek Lewandowski > > > pt., 21 lut 2025 o 15:56 Jeremy Hanna napisał(a): >> Congratulations Caleb. Thank you for all of your contribu

Re: New committers: Maxwell Guo and Dmitry Konstantinov

Congratulations to you both; glad to have you as part of the community. On Fri, Feb 21, 2025, at 1:36 AM, Berenguer Blasi wrote: > Congrats! > > On 20/2/25 21:29, Jeremiah Jordan wrote: >> Congrats to both of you! Thank you for the contributions you have been >> making to the project! >> >> On

Re: Welcome Jeremiah Jordan to the PMC

Congrats Jeremiah! I know you're excited to have yet another email list to attend to, aren't you? :D On Fri, Feb 14, 2025, at 1:29 PM, Jeremiah Jordan wrote: > Thanks all! Excited to continue being a part of the project in this new role. > > -Jeremiah Jordan > > On Feb 14, 2025 at 12:23:17 PM

Re: [Discuss] Decoupling java driver dependency from server code; migrate tools and tests to 4.x driver

Unifying on latest java driver in the codebase and beefing up SimpleClient to be used specifically in the simulator makes sense to me. The more we exercise the driver in our testing stack the better, but to your point Benedict, the lift to get the driver itself simulator compatible seems like it

Re: Merging compaction improvements to 5.0

> If folks want to point to the docs for each cloud provider for the maximum > block size per IO request, we can certainly document that somewhere. Meh, that will probably change on their side over time right? At most I'd say we link to their docs, but even then those external links will go stale

Re: [VOTE] Release Apache Cassandra Java Driver 4.19.0

+1 On Mon, Feb 10, 2025, at 6:34 PM, Nate McCall wrote: > +1 > Verified sigs and artifact coordinates. > > On Tue, Feb 11, 2025 at 12:30 PM Brandon Williams wrote: >> +1 >> >> Checked sha/sig, maven artifacts, built on j8. >> >> Kind Regards, >> Brandon >> >> On Thu, Feb 6, 2025 at 4:34 PM Br

Re: [VOTE] CEP-45: Mutation Tracking

+1 On Mon, Feb 3, 2025, at 1:33 PM, Blake Eggleston wrote: > Hi dev@, > > I’d like to start the voting for CEP-45: Mutation Tracking > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking > Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m

February 2025 project status update

Welcome to February. An oddly spelled month with a peculiar and inconsistent number of days. *Releases: * We find ourselves in the somewhat odd place where release votes passed for 3.0, 3.11, and 4.0, however there were insufficient votes on 4.1 and 5.0 to release those branches. Expect more to

Re: [DISCUSS] 5.1 should be 6.0

ine upgrade targets, I would suggest > we change that to T-3 so you encompass all “currently supported” releases at > the time the new branch is GAed. > > -Jeremiah > > On Jan 29, 2025 at 10:49:17 AM, Josh McKenzie wrote: >> >> To clarify, when I say unspoken it

Re: [DISCUSS] 5.1 should be 6.0

t our > collective preferences that simply can’t functionally be codified due to the > fact nobody is willing to actually argue this is a good thing. Sometimes no > individual likes what happens, but it’s what the polity actually wants, > collectively. That’s fine, let’s be at peace

Re: Capabilities

e coupling it would introduce >>>>>> between components of different levels of criticality. You can derisk it >>>>>> partially by having separate logs (which might not be trivial to >>>>>> implement). But unless you also duplicate all the TCM logic i

Re: [DISCUSS] 5.1 should be 6.0

hat is, we have always numbered using some combination of semver and how >> exciting the release is, and backed all other decisions out of whatever was >> reasonable once that decision was made. >> >> Which basically means a new major every 1 or 2 releases depending on how

Re: [DISCUSS] 5.1 should be 6.0

nly immediately break, if the > motivation is avoiding extra release steps, I would prefer we just avoid > extra release steps by eg running nightly upgrade tests rather than pre > commit, or making the tests faster, or waiting until the test matrix actually > causes anything to

Re: [DISCUSS] 5.1 should be 6.0

> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers > We have far fewer (and more effective?) JVM Upgrade DTests. > There we only need 8x medium (3 cpu, 5GB ram) servers Does anyone have a strong understanding of the coverage and value offered by the python upgrade dtests

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

ly_internal_property: false > > I do not think we want to have them renamed / under different configuration > sections in yaml. I get that they are "internal" etc but we just don't know > how / where it is used and deployed and just blindly renaming them is not a >

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

This may be an off-base comparison, but this reminds me of struggles we've had getting to 0 failing unit tests before and the debates on fencing off a snapshot of the current "failure set" so you can have a set point where no further degradation is allowed in a primary data set. All of which is

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

+1 to making hidden properties explicit. No way to tell whether it's a mistake or not atm. On Fri, Jan 24, 2025, at 9:36 AM, Štefan Miklošovič wrote: > > > On Fri, Jan 24, 2025 at 3:27 PM Paulo Motta wrote: >> > from time to time I see configuration properties in Config.java and they >> > are

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.1

+1 On Thu, Jan 23, 2025, at 9:58 AM, Štefan Miklošovič wrote: > +1 > > On Sat, Jan 18, 2025 at 10:54 PM Bret McGuire wrote: >> Greetings all! >> >> >>I’m proposing the Cassandra Java Driver 3.12.1 for release. >> >> >> sha1: 873e6f764a499bd9c5a42cafa53dc77184711eea >> >> git: https://gi

Re: What branches should perf fixes be targeting

> Of note, it's been 13 months since 5.0 GA. :) On a scale of 1-10, I'm a 10 out of 10 for being wrong here. It's been 13 months *since we initially intended to release 5.0*. Stabilization of CI and some bugs took us to mid 2024. So it's not as bad as all that. Thanks to those that pointed this

Re: Patrick McFadin joins the PMC

Congrats Patrick! On Wed, Jan 22, 2025, at 12:06 PM, Dmitry Konstantinov wrote: > Congratulations! > > On Wed, 22 Jan 2025 at 16:36, Russell Spitzer > wrote: >> Congratulations! >> >> On Wed, Jan 22, 2025 at 10:30 AM Ekaterina Dimitrova >> wrote: >>> Congratulations, Patrick 🎉 >>> >>> On We

Re: What branches should perf fixes be targeting

> When we speak about minor releases - it looks like the release process is > much slower and not so predictable, it can be a year or even more before I > can get any minor release which includes a change, and nobody can say even a > preliminary date for it. This is one of the reasons I keep agi

Re: [DISCUSS] Bracing style on trunk

>>>>> issues with git blame, there are a lot of other in-flight projects > > > >>>>> that would have to deal with this, there are a lot of tickets > > > >>>>> waiting for review that would be affected. > > > >>

Re: Checkstyle as style contract for Cassandra

on the CI saves both the contributor and the reviewer >>>>>>> time in reading boring guides and writing code. So I would +1 for both >>>>>>> enforcing checkstyle lint (with braces on a new line), validating it >>>>>>> on CI, and at the same time fixi

[DISCUSS] Review Guide for the project

See thread "Checkstyle as style contract for Cassandra ". One area where we haven't formalized much guidance is around our code review culture as a project. I've worked with guides based on google's "How to do a code review

[DISCUSS] Bracing style on trunk

Trying to break out discussions here to keep things moving - see thread "Checkstyle as style contract for Cassandra " One topic that came up on the thread was whether we were collectively happy with our current newline bracing st

Re: Checkstyle as style contract for Cassandra

3 [DISCUSS] threads for each of the above 3 topics and put this thread to rest? On Fri, Jan 17, 2025, at 6:36 AM, Benedict wrote: > > I would support adopting a review guide based on this one. > >> On 16 Jan 2025, at 15:36, Josh McKenzie wrote: >>  >>> Pe

Re: Checkstyle as style contract for Cassandra

gt; IDEA thing, braces might be similar) but we have not refactored all >> codebase. We said that once the code style / enforcement is in place, then >> all these changes will be done naturally as new code is added or modified. >> That means that it will not be one "big bang&qu

Re: Checkstyle as style contract for Cassandra

t we want can be a pain as >>> folks who have explored it have outlined. So then I think it comes back to >>> Josh’s question (to paraphrase) of “is it good enough as is”? And as an >>> aside we might want to ask ourselves “why have we chosen a style guide that >>&g

Re: [DISCUSS] CEP-45: Mutation Tracking

> > > On Jan 9, 2025, at 2:07 PM, Blake Eggleston wrote: > > > > So the ids themselves are in the memtable and are accessible as soon as > > they’re written, and need to be for the read path to work. > > > > We’re not able to reconcile the ids until we can gu

Re: Checkstyle as style contract for Cassandra

contribution, and to help avoid folk getting > bogged down in style sniping. > > >> On 16 Jan 2025, at 14:08, Josh McKenzie wrote: >>  >> Right now our codebase is pretty consistent, especially for not having a >> linter enforcing this kind of thing. Are we try

Re: Checkstyle as style contract for Cassandra

Right now our codebase is pretty consistent, especially for not having a linter enforcing this kind of thing. Are we trying to solve for codebase consistency, education of new contributors, both? Neither? If just solving for consistency I'd argue we're good. If educating new contributors, the C

Re: [DISCUSS] CEP-45: Mutation Tracking

parate to it can reliably support automatic reconciliation > cadences that are higher than what you can do with incremental repair today, > but that’s the short answer. > > > > It's also likely that the concept of log truncation will be removed in favor > of going straight

Re: [DISCUSS] CEP-45: Mutation Tracking

Question re: Log Truncation (emphasis mine): > When the cluster is operating normally, logs entries can be discarded once > they are older than the last reconciliation time of their

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

+1 On Wed, Jan 8, 2025, at 11:59 PM, Tolbert, Andy wrote: > +1 (nb) > > On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink wrote: >> +1 >> >> On Wed, Jan 8, 2025 at 4:14 PM Bret McGuire wrote: >>> Greetings all! >>> >>> >>>I’m proposing the Cassandra Java Driver 3.12.0 for release. This >>>

Re: [DISCUSS] Usage of "var" instead of types in the code

roject with -Dno-checkstyle=true. > > There were more people coming, saying they don't want to see that anywhere, > after we banned that in the production code and that somehow tilted the scale > in favor of banning for me but it was too late. > > On Mon, Jan 6, 2025 at

Re: Capabilities

ing it, and that we should exercise that risk judiciously. This >>>> has zero to do with the amount of data we’re pushing through it, and 100% >>>> to do with writing bad code. >>>> >>>> We treated gossip carefully in part because it was hard to work wit

Re: [DISCUSS] Usage of "var" instead of types in the code

> I would like to remove this altogether from tests and ban it too in a week or > two. Don't think we had clear consensus here. On Sun, Jan 5, 2025, at 5:42 PM, Štefan Miklošovič wrote: > I would like to remove this altogether from tests and ban it too in a week or > two. > > I see that Bereng

Re: Capabilities

To play the devil's advocate - the more we exercise TCM the more bugs we suss out. To Jon's point, the volume of information we're talking about here in terms of capabilities dissemination shouldn't stress TCM at all. I think a reasonable heuristic for relying on TCM for something is whether th

Re: Capabilities

Strong +1. Much like having repair scheduling built in to the ecosystem, this feels like table stakes for having a self-contained, usable distributed database. On Wed, Dec 18, 2024, at 6:11 PM, Dinesh Joshi wrote: > Hi Jordan, > > Thank you for starting this thread. This is a great idea. From a

Re: Supporting 2.2 -> 5.0 upgrades

> will not happen until we are out of Ant as doing this multi jar / subproject > mumbo jumbo is not too much appealing to ... anybody? There's some folks working on a CEP around our build system and supporting a shared library (came up in a thread on #cassandra-dev; that's the extent of my knowl

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

are not actively being worked > > on. They are currently broken. Calling them ‘alpha’ makes ‘alpha’ > > overloaded and less useful. > > > > On 12 Dec 2024, at 14:00, Josh McKenzie wrote: > > > > But we also need an approved non-euphemism for features like MVs

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

’s superseded. > > >> -1 on unstable. It's way too many words than are needed. Three is a >> magic number and fits: >> >> Preview >> Beta >> GA > >> On 11 Dec 2024, at 18:50, Josh McKenzie wrote: >> >> A structured, discip

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

essary policy to proceed today, and leave future refinements >>> >> for later when the relevant context arises. >>> >> >>> >> On 10 Dec 2024, at 13:00, Benedict Elliott Smith >>> >> wrote: >>> >> >>> >> I

2024 year in review

It's been a long time since I sent out a status update. Let's round up 2024, and let's see if we can't have more regular updates in 2025 shall we? First, some vanity metrics on the year in review: Community Health and Activity: - Tickets created: 840 - Tickets fixed: 518 - Tickets created in 20

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

t > >> use euphemisms, and for this reason I don’t like unstable (this could for > >> instance simply mean API unstable). If we intend to never need this > >> descriptor, we should avoid bike-shedding and insert a “placeholder” for > >> now to be refined as a

Re: [DISCUSS] 5.1 should be 6.0

ot be strictly breaking, but they’re > > >> fundamentally very very different, so even with semver as the only > > >> standard, I think you can justify a major. > > >> > > >> But also, let’s just acknowledge that marketing is a thing and bump the > >

Re: [DISCUSS] 5.1 should be 6.0

Currently we reserve MAJOR in semver changes for API breaking only: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting: That's consistent w/semver itself: link : > Given

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

+1 to this classification with one addition. I think we need to augment this with formalization on what we do with features we don't recommend people use (i.e. MV in their current incarnation). For something retroactively found to be unstable, we could add an "Unstable" qualification for it, lea

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

than a major >>> release. >>> >>> Java versions, for example, should really move out of "beta" quickly. We >>> test against it, and we're not going to drop new versions. So if we're >>> looking at C* 5.0, we should move Java 17

[DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Jon stated: > Side note: I think experimental has been over-used and has lost all meaning. > How is Java 17 experimental? Very confusing for the community. Dinesh followed with: > Philosophically, as a project, we should wait until critical features like > these reach a certain level of maturi

Re: [DISCUSS] Delivery of CASSANDRA-19556 Add guardrail to block DDL/DCL queries

ly-introduced system property in > trunk? Removing it mercilessly in the trunk without any deprecation? > > On Wed, Nov 20, 2024 at 12:57 PM Josh McKenzie wrote: >> __ >>> they have to turn off a node, set the property and turn it back on. This is >>> not optimal >&g

Re: [DISCUSS] Delivery of CASSANDRA-19556 Add guardrail to block DDL/DCL queries

> they have to turn off a node, set the property and turn it back on. This is > not optimal We have quite a few other features that have this same paradigm to disable/enable them. Is there a reason it's worse in this case than those, at least on the 4.0 release? Users will have to bounce up to t

Re: Status of CEP-1

g/jira/browse/CASSANDRASC-122 > > > > [4] https://issues.apache.org/jira/browse/CASSANDRASC-160 > > > > [5] https://issues.apache.org/jira/browse/CASSANDRASC-161 > > > > [6] https://issues.apache.org/jira/browse/CASSANDRASC-159 > > > > [7] https://issu

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Tue, Nov 5, 2024, at 4:28 PM, Jaydeep Chovatia wrote: > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra >

Re: Backporting CASSANDRA-17812 to 4.x

I'm neutral to the backport. In terms of the letter of the law, I can see the argument either way of it being an improvement or a bugfix. Definitely wouldn't -1 a backport. On Tue, Nov 5, 2024, at 7:23 AM, Mick Semb Wever wrote: > Can you please put the ticket description in the email. Saves us

Re: [DISCUSS] Usage of "var" instead of types in the code

t;> >>> *boolean *contains(String name) >>> { >>> *var *names = allNames(); >>> *return *names.contains(name); >>> } >> Then, allNames is refactored to return List later. The contains method then >> runs slower. >>> *L

Re: [DISCUSS] Usage of "var" instead of types in the code

(sorry for the double-post) Jeremy Hanna kicked this link to a style guideline re: inference my way. Interesting read for those that are curious: https://openjdk.org/projects/amber/guides/lvti-style-guide On Tue, Oct 29, 2024, at 2:47 PM, Josh McKenzie wrote: > To illustrate my position f

Re: [DISCUSS] Usage of "var" instead of types in the code

To illustrate my position from above: Good usage: > Collection names = new ArrayList<>(); becomes > var names = new ArrayList(); Bad usage: > Collection names = myObject.getNames(); becomes > var names = myObject.getNames(); Effectively, anything that's not clearly redundant in assignment should

Re: [DISCUSS] Usage of "var" instead of types in the code

Not having type inference has made me grumpy about working on our codebase vs. tinkering in C# for the past decade. So you can guess where I stand on that. :) I'm all for us adopting it in scenarios where the type of an object is immediately obvious (i.e. doesn't require navigation to a method o

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

I'm a very strong +1 to having the default functionality be to copy *ALL* options. Intuitively, as a user, if I tell a software system to make a clone of something I don't expect it to be shallow or a subset defined by some external developer somewhere. I expect it to be a clone. Adding in som

Re: [Discuss] Repair inside C*

t 2024 at 01:40, Jaydeep Chovatia >> wrote: >>> Sorry, there is a typo in the CEP-37 link; here is the correct link >>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+Apache+Cassandra+Unified+Repair+Solution> >>> >>> >>> On Th

Re: [DISCUSS] Modeling JIRA fix version for subprojects

+1 to CASS- shorthand. Think you're going to just have to agree to disagree on this one Stefan; clear majority consensus on it on this thread afaict. On Sat, Oct 19, 2024, at 8:55 AM, Mick Semb Wever wrote: >> Isn't it weird that you said that we should not save characters at the cost >> of

Re: [VOTE] CEP-44: Kafka integration for Cassandra CDC using Sidecar

+1 On Thu, Oct 17, 2024, at 2:51 PM, Yifan Cai wrote: > +1 nb > > > *From:* Brandon Williams > *Sent:* Thursday, October 17, 2024 11:47:13 AM > *To:* dev@cassandra.apache.org > *Subject:* Re: [VOTE] CEP-44: Kafka integration for Cassandra CDC using > Sidecar > > +1 > > Kind Regards, > Bran

  1   2   3   4   5   6   7   >