I can definitely see a logic in not removing. When I saw deprecated
annotations for the first time after I mapped where we deprecated it, my
initial desire was to invent some logic to remove it all after some period
of time but that is not a good idea after all.
We had a thread about this here (1)
On Mon, Apr 21, 2025 at 3:12 PM Miklosovic, Stefan via dev <
dev@cassandra.apache.org> wrote:
> Seeing this thread where we discuss about deprecations, I use this for
> asking if there is some action to take when looking into (1) I conducted a
> small research for some time ago.
>
>
>
> There are
On Mon, Apr 21, 2025 at 9:20 AM Josh McKenzie wrote:
> Honestly, excepting thrift support I can't remember something we removed
> from the system in this way so a lot of this is perhaps premature process
> optimization.
>
That is definitely fair, as long as we don't go deprecating things after a
912
From: Josh McKenzie
Date: Monday, 21 April 2025 at 15:20
To: Benedict , dev
Subject: Re: [DISCUSS] How we version our releases
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
Honestly, excepting thrift support I can't remember something we removed from
the system in th
Honestly, excepting thrift support I can't remember something we removed from
the system in this way so a lot of this is perhaps premature process
optimization.
And I agree w/you here Benedict; given we can shim in translation from new
functionality to continue to support previous APIs (thinkin
I’d much rather we agree to try NOT to deprecate or break things full stop. 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 should
> I personally feel that patch level fixes should count as “next major” to
> avoid this problem.
+1.
Let me try and distill yours and Joey's thoughts:
1. Any release after a MAJOR.0.0 qualifies as MAJOR+1 in terms of deprecation
2. On deprecation, explain the path forward to users (move to diff
If 7.0.0 was released then we wouldn't be removing features from it, even
if we go back in time to 6.0 and mark something as deprecated. As a
community I assume we all agree that's unreasonable.
If something is marked as deprecated in a major release, that status
shouldn't be changing out from un
> Assuming there's no major flaws in my reasoning above
We can release 4.0.x today, while 5.0.x exists… so lets play with that
We release 7.0.0, hooray !!! But during this we find a bug in 6.0.x that we
back port, which deprecates something, so 6.0.x releases at the same time as
7.0.0… so can 7
I feel like the "T-1" approach only really makes sense if there are
additional time guarantees with features that have left experimental
status. I agree it is good to shift our versions to the left (folks already
treated the concatenation of major.minor as our major), but I agree
with Benedict and
> One thing that would be great to be super clear about, if a patch release
> deprecates a feature, does that act as if the next major deprecated it, or
> the current major?
Hm. So thinking this through, the deprecate-then-release model gives us 2
affordances:
1. A minimum time horizon where so
> Does it mean that one has to flag a feature as deprecated in the unreleased
> version N, wait until when N is released (deprecating for one major cycle),
> and then finally make the breaking change in N + 1?
My understanding is things are not different than before, we just don’t do
minors; wh
Just realized that the other thread is for [vote]. Posting my question here
instead...
I would like to get a better understanding of "but only for features that
have already been deprecated for one major release cycle."
Does it mean that one has to flag a feature as deprecated in the unreleased
v
> Does this imply that each release is allowed to make breaking changes
> (assuming they followed the “correct” deprecation process)? My first
> instinct is to not like this
Does the clarification in the earlier thread help shift your perspective /
address your concerns here David?
Will leave
+1.
It's the proper signal to the community. A .1 release could still be done
as an exception, but I have a hard time thinking of a case other than
supporting a newer JDK without any other changes.
On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan wrote:
> +1 from me.
> No more wondering what th
> So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to
> make breaking changes (assuming they followed the “correct” deprecation
> process)?
Yes and no.
A release can't make a breaking change *relative to the immediately preceding
release*, if something has been deprecat
+1 from me.
No more 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 "5.1 should be 6.0".
>
> I think it's important t
I proposed dropping Minor versions a few years ago so I’m cool with this, but regarding policies I do think we’d be better off just creating a version compatibility matrix and quit agonising over it. With N policies across N releases I’m not sure they’re providing much certainty to users. We really
On Thu, 10 Apr 2025 at 22:54, Josh McKenzie wrote:
> …
> So here's what I'm thinking: a new release strategy that doesn't use
> .MINOR of semver. Goals:
> - Simplify versioning for end users
> - Provide clearer contracts for users as to what they can expect in
> releases
> - Simplify support for
> So here's what I'm thinking: a new release strategy that doesn't use .MINOR
> of semver. Goals:
So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to
make breaking changes (assuming they followed the “correct” deprecation
process)? My first instinct is to not like this,
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
21 matches
Mail list logo
