If we drop Java 8 support then I would think we need to go to 5.0. That definitely qualifies to me as “this release is not backwards compatible with 4.1”.
-Jeremiah > On Sep 26, 2022, at 12:12 PM, Aleksey Yeshchenko <alek...@apple.com> wrote: > > Don’t have an opinion on designating 4.2 as 5.0 instead, though it might be a > nice idea for marketing reasons, if enough splashy features make it into it. > > If or when we go with 5.0 however, we don’t have to drop any compatibility > with older versions just because our SemVer rules technically allow us to. > Extended compatibility is a worthy feature to have and should be kept for as > long as feasible. > > — > AY > >> On 26 Sep 2022, at 18:00, Mick Semb Wever <m...@apache.org >> <mailto:m...@apache.org>> wrote: >> >> >> More precisely, do we want to drop anything 4.x deprecated, or do we want to >> drop support in trunk for upgrading from 3.x ? And are we ready to commit >> now to saying let trunk be 5.0 ? >> >> Our SemVer versioning rules, being operator rather than user facing, state >> that these compatibility concerns are the requirements that warrant a major >> version jump. (Because we are otherwise always to be strict with providing >> compatibility.) >> >> A separate question: do we want our major version to jump simply because we >> drop support for an older JDK? My opinion is that we shouldn't, as this >> would churn our version numbers and leave us less in control of (minimising) >> the upgrade paths we force our users to go through. And that's not to say >> new JDKs won't force other changes that themselves justify the jump. >> >> >> >
