I’m confused: do people pay attention to version numbers or not? If not, how does it affect upgrades? If they do, surely it matters for communication, including marketing? We aren’t only a technical panel.
I also reject the premise that a major bump has to have any effect on our backwards compatibility *besides that which we agree*. We should make this clear in fact: no breaking changes without dev list sign-off, whatever the version change. A major bump is not an excuse to break things. I personally think some folk are way too wed to their interpretation of semver. The value is minimal. So long as a major version is bumped *at least* when there’s a significant breaking change, the communication goal has been met: a user who understands semver knows to look at NEWS.txt - which they should be doing anyway. I once ran a database that did not follow semver and everything was fine. You read the notes and you ran the upgrade, same as any other product. So, bumping major here just means folk will do what they’re meant to do anyway. Why are we arguing about this so much? If we want to bump major, let’s just bump major? This feels like the very definition of bike shedding. > On 17 Oct 2022, at 03:20, 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. >
