> it turned out to be a lot more complicated than it looks on first blush. The story of our lives. :)
> the first release from the 4.x line was in... spring of 2019 I believe. It's > now summer of 2026. I'd argue that's _more_ than enough time for upgrades to > have happened I'm of two minds on this. From an application revision perspective: 100% agree. From a infrastructure software perspective, I think most people would prefer it if infra worked on day 1 and then **literally never changed**. We don't really have any way of knowing how many applications are out there on the 3.x line still relying on that API; unless we collectively believe the API in 4.x was so compelling the vast majority of users would have elected to proactively migrate (which... I don't have that impression but it's not grounded in data - I'm receptive to other perspectives here), people are having to triage a horizontal upgrade to move to a newer API w/out delivering business value vs. other features that do. So I would strongly suspect there's a lot more people still actively depending on 3.x than we'd like. > a shim like what you're describing is explicitly saying that we want the 3.x > _API_ to stick around. There's no active development on the 3.x line. There > are no new features going into that line (the only changes it sees are > security updates). I don't want to support the 3.x API indefinitely; the > reality is we've moved on. I don't think it explicitly communicates we want the API to stick around any more than, say, continuing to support thrift with security updates but a frozen API would communicate a positive desire for thrift to still be in use. I think it's more an acknowledgement that there's a strong disconnect between what we know as developers in an ecosystem and the consumers and dependents upon the APIs we draft. This is part of why we landed on the "Consider all APIs to live forever and never be removed" perspective with core C*. I think the perfect example of the shape of user I'm thinking of is someone who has an application that's 5 years old, built on the 3.x line, has had no augmentation or feature addition in 5 years (if it ain't broke...), and have *zero* incentive to refactor an application to use a new API that for their purposes is feature-neutral to their old use-case. Moving to a new version is strictly a net negative for people like that as that change will introduce instability and bugs. I think the argument I'm making here (and I don't like it) is that, on balance, we should consider the 3.x **API** something we have to support indefinitely. At least when it comes to security updates - certainly not back-porting new functionality or anything. I'm 100% with you that anyone working on any new application should use the latest stable API, but we're an old project with a lot (and I mean *a lot*) of legacy use-cases. So that would mean that, if the 4.x driver itself doesn't have 3.x **API** support, we'd need to add that there before EOL'ing the 3.x line. Which really is a shim by any other name; if we implement 3.x API support in the 4.x line and on it's really just that. I dunno. I'm very curious / hopeful to hear other perspectives that aren't my conclusion (please ;) ), but my personal experience in the last decade on this project is that retiring APIs that require application side changes is a recipe for disaster. Has anybody taken a day or two to get a handle on how much of a lift it'd be to add a 3.x API compatibility layer to the 4.x driver? It'd probably be helpful to at least gather data on the side of this coupling where we can to help ground the discussion in data instead of trauma and vibes. :) On Fri, Jun 26, 2026, at 4:27 PM, Bret McGuire wrote: > I think there was a pretty decent argument for something along the lines > of what you're describing Josh, but I guess I'd argue the argument was > strongest when the first release of the 4.x line came out. In fact I believe > there _was_ some work done on something like what you're describing but (if > I'm remembering correctly) it never saw the light of day, in no small measure > because it turned out to be a lot more complicated than it looks on first > blush. I can think of a couple different areas where that would be fairly > problematic but I'll defer to some of the folks who were more involved in > that effort if they have more details and/or clarification on that point. > > Either way, the first release from the 4.x line was in... spring of 2019 I > believe. It's now summer of 2026. I'd argue that's _more_ than enough time > for upgrades to have happened. I'm struggling to think of other libraries > which would go to these lengths to keep older APIs around for so long after > new development has moved on. And that's really what we're talking about > here; a shim like what you're describing is explicitly saying that we want > the 3.x _API_ to stick around. There's no active development on the 3.x > line. There are no new features going into that line (the only changes it > sees are security updates). I don't want to support the 3.x API > indefinitely; the reality is we've moved on. > > The parallel with six is interesting. I've gone back and forth on this > point but there's certainly an argument that a shim layer for a _programming > language_ is probably more necessary than one for a library API, but like I > say I haven't thought that one through enough to say for sure. > > Speaking only for myself I'm not opposed to _the idea_ of a shim at all; > if somebody wants to put in the work it's something we can talk about. I > just don't want the Java driver team to be responsible for creating (and > maintaining) such a shim indefinitely. For me a solid parallel is what we're > doing with the Python driver; we've deprecated (and will be removing) three > of the less-used executors but we're not suggesting they can't be forked and > maintained by somebody else. We're just saying we have limited resources and > we can't maintain everything indefinitely. I hear you about past experience > with breaking updates (and no clear update path) but DataStax also went to > great lengths to try and remove as little as possible between versions... and > I guess I'd argue that hamstrung development somewhat. > > To that point (and indirectly related to the topic at hand): part of _my_ > rationale for wanting to go to a 5.x is to get us back in the habit of > regarding major version bumps as a normal part of software development. 4.x > was _so_ disruptive that we got a bit nervous about considering another major > bump even when it made sense. I'd rather move us towards a more familiar > model of software development: major version bumps are a fact of life, use > them when they're appropriate but also do your best not to change the world > when you do. No one (and I mean _no one_) is interested in repeating the > experience of the 4.x conversion. But we can't be afraid to do a major > version bump when it makes sense. > > Okay, that's enough from me, somebody else should talk now. :) > > - Bret - > > > On Fri, Jun 26, 2026 at 7:57 AM Josh McKenzie <[email protected]> wrote: >> __ >>> Unlike the transition from 3.x to 4.x, this release will not introduce >>> significant API breakage. >> >>> We also plan to sunset the 3.x line in the near future, and strongly >>> encourage users to upgrade to the 4.x series. >> I remember talking with Adam Holmberg and some other driver devs back in the >> day about the possibility of an API shim bridging the 3.x and 4.x line. >> Something similar to how the python community ended up introducing six >> <https://pypi.org/project/six/> to try and bridge their pretty painful gap >> in their extensive API breakages between those majors. I think we should >> revisit that idea now that we have some tooling that could make the process >> of designing and implementing a "nuts and bolts plumbing" bridge layer like >> that much lower effort. >> >> We have a long history on this project ecosystem (not drivers; cassandra :) >> ) of introducing API breakages without a paved-path for app devs and >> operators to transition the pre -> post world; avoiding the community >> fracture and long-term forks that arise from this would be very much worth >> the effort IMO. >> >> On Thu, Jun 25, 2026, at 5:07 PM, Jane H wrote: >>> Hi all, >>> >>> We’re pleased to share the release plan for the Apache Cassandra Java >>> Driver. >>> >>> The next release will be a major version, 5.0. Unlike the transition from >>> 3.x to 4.x, this release will not introduce significant API breakage. >>> However, we do plan to drop support for Java 8 and Java 11, making Java 17 >>> the minimum supported version. >>> >>> Our rationale is as follows: >>> 1. End-of-life status. Both Java 8 and Java 11 have reached end of life >>> (Oracle Premier Support)—Java 8 in March 2022 and Java 11 in September 2023. >>> 2. User adoption trends. Based on our recent Java Driver user survey (22 >>> responses): >>> • 75% are already running the driver on Java 17 or later >>> • 90% believe Java 17 or newer should be the minimum supported version for >>> 5.0 >>> • 52% Java 17 >>> • 38% Java 21 >>> • Modern platform benefits. Building on Java 17 enables us to take >>> advantage of modern language features, tooling, and libraries—for example, >>> adopting Jackson 3. >>> >>> In addition, the next 3.x release will be 3.13.0, which will support JDK 8+ >>> (instead of JDK 6). We also plan to sunset the 3.x line in the near future, >>> and strongly encourage users to upgrade to the 4.x series. >>> To help with migration, please refer to the upgrade guide: >>> https://apache.github.io/cassandra-java-driver/4.19.0/upgrade-README/ >>> >>> Cheers, >>> The Apache Cassandra Java Driver Developers >>
