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
>
>
>
