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