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, at 9:19 PM, Mick Semb Wever <m...@apache.org> wrote: > > > 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), > - CEP-21 (once accepted) will be easier without having to support 3.x > compatibility. It is also my understanding that CEP-15 requires CEP-21. > > > > Otherwise, inline replies on the topics of why operator centric major version > delimitation, the amount of resources required to provide extended > compatibility, and why dropping support for one JDK is not (in itself) a > compatibility breakage. > > > 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. > > > Aleksey, I am not keen on the notion of versioning by marketing. Our > versioning can be valuable and intuitive feedback to operators, making their > upgrades simpler and safer, if we can keep it consistent. > > If marketing cannot market Accord and Transaction Cluster Metadata, I think > we have bigger problems on our hands. > > Marketing can be seen as external to engineering, and should not be imposed > by our semver notion of major versions, they should be entirely free to use > whatever adjectives they like against each annual release. > > A strong dose of personal opinion here, but I really think we're over-playing > the leading digit of our version numbers against a user base that's far more > diverse and intelligent than we're giving them credit for. My own anecdote is > that I would struggle to tell you the current version number of many other > technologies. And I experience regularly that many users don't immediately > know the version they are running when asked. We should embrace such > cluelessness – they have more important things to know and to remember, and > it's easy enough to figure it out when needed. > > One of the common challenges users come to us (C* consulting) is to deal with > upgrades. Every little bit of simplification they can get from us to > understand and prepare for the impacts of non-patch upgrades goes a long way. > Many have been badly burnt by upgrades, it's not as easy as we'd like to > think it is. > > This touches on why I don't believe major versions should be tied to dropping > JDKs: there's a lot more going on underneath C* than just the JDK. Users are > requested to keep their systems up to date, and this involves the kernel, > dist, native libraries, python, and drivers. We need to be encouraging users > to be keeping their systems up to date between upgrades, not when performing > upgrades. > > The more we can do to de-risk major upgrades the better. > > > 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. > > > I totally agree that extended compatibility is a worthy feature. But… > extended compatibility has overhead (on more than just code). Restricting > upgrade paths to reduce testing costs seems an obvious example. The problem I > see is that once we make that decision to increment the major we then slowly > but surely stop caring for compatibility over non-adjacent majors. How do we > minimise overload on our limited community engineering resources, while > ensuring extended compatibility ? > > > 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, I agree and disagree here, though you have definitely changed my > thinking around this :-) > > I'm in favour of separating JDK support from any direct notion of C* > compatibility, for the purpose of de-risking major upgrades via promoting the > upgrade of runtime dependencies separately. We can do this if we also say, > throughout any major version there must be one JDK consistently supported. > > While I disagree that dropping a single JDK (in itself) implies compatibility > is broken; we must not break compatibility from one major to the next; > dropping all supported JDKs would indeed break compatibility. For example, > with 3.0 and 3.11 only supporting JDK8, this means that all 4.x versions must > also support JDK8, and any new version that no longer has any JDKs in common > with 3.x must become 5.x > > So I would totally agree with your statement, if it were slightly tweaked as: > If we drop Java 8 support then I would think we need to go to 5.0. That > qualifies as “this release is not backwards compatible with 3.0 or 3.11”. > > This will also give us more room to move, on the assumption we will want a > major roughly every three years to avoid users upgrading from unmaintained > versions, and we don't want a major every year as that would burn operators. > > If we can get some alignment on this I will put together a PR to better > document these things, we need a page for our JDK support matrix, and a page > on upgrade requirements. >
