As long as this doesn’t break the CLI interface, +1 from me; less dependencies
are better and valuable work!
> On Sep 29, 2022, at 6:52 AM, Berenguer Blasi wrote:
>
> +1
>
> On 29/9/22 15:42, Derek Chen-Becker wrote:
>> +1 from me. It sounds like a good opportunity!
>>
>> Cheers,
>>
>> Derek
So the TL;DR here is that you (Mick) now also agree we should move the
> version to 5.0? I haven’t seen any other arguments for staying on 4.2, so
> should we just move the version number to 5.0 now? Do we want to have a
> VOTE thread for it? Or should we just do it?
>
I was never against 5.0,
So the TL;DR here is that you (Mick) now also agree we should move the version
to 5.0? I haven’t seen any other arguments for staying on 4.2, so should we
just move the version number to 5.0 now? Do we want to have a VOTE thread for
it? Or should we just do it?
-Jeremiah
> On Oct 16, 2022,
Sorry, I did find your email which I have seemingly missed with:
>
Thanks :-)
> > To summarise, we need to make 4.2 into 5.0, as
> > - we need to remove (the already deprecated) JavaScript UDFs to add JDK
> 17,
> > - dropping support for JDK8 would make it impossible to upgrade from 3.x
> (see
It’s always arbitrary. We don’t bump major version when we make incompatible
behavioural changes in bug fixes, for instance. It’s always a judgement: this
release has important changes you should take a close look at. That’s all it
means.
Stuff that’s literally arbitrated is always somewhat in
Sorry, I did find your email which I have seemingly missed with:
> To summarise, we need to make 4.2 into 5.0, as
> - we need to remove (the already deprecated) JavaScript UDFs to add JDK 17,
> - dropping support for JDK8 would make it impossible to upgrade from 3.x (see
> explanation below),
>
Could you be more explicit? Are you saying we should release 5.0 instead of 4.2
(which I'm assuming you're advocating for), or are you saying we should release
4.2?
I still do not understand the question, really. It can't be more important to
be consistent with versioning than for versions to m
I'm also a bit confused by the original question: if there's a proposal to
> release 4.2 as 5.0, let's hear out why and just vote for it (list reasons,
> and let everyone express their opinions about why this does or does not
> warrant the version bump). If there are no reasons for us to do, I'm no
I'm also a bit confused by the original question: if there's a proposal to
release 4.2 as 5.0, let's hear out why and just vote for it (list reasons, and
let everyone express their opinions about why this does or does not warrant the
version bump). If there are no reasons for us to do, I'm not s
> I have a minor doc fix for the CircleCI generate.sh script:
>
> https://github.com/apache/cassandra/pull/1902
>
> @adelapena made the change to the script that added the flag, so maybe he
> could take a quick look. On the CircleCI build itself, I have a small PR to
> make the offheap dtests run (
So… what’s the problem with bumping our major version because we want to
communicate a release is “major” rather than has a breaking change - ie that we
think users should feel incentivised to upgrade to it for whatever reason?
Also, who is talking about never making breaking changes? Breaking c
11 matches
Mail list logo
