> qualifies to me as “this release is not backwards compatible with 4.1”. I'm +1 on considering dropping a specific JDK's support as being a non-backwards compatible change.
On Mon, Sep 26, 2022, at 1:34 PM, Jeremiah D Jordan wrote: > 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> 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. >>> >>> >>>
