So… what’s the problem with bumping our major version because we want to communicate a release is “major” rather than has a breaking change - ie that we think users should feel incentivised to upgrade to it for whatever reason?
Also, who is talking about never making breaking changes? Breaking changes should simply *always* be agreed on list, whatever the version number. The default should be no breaking changes, it should be a conscious project-level decision to break an element of compatibility. > On 17 Oct 2022, at 07:56, Mick Semb Wever <m...@apache.org> wrote: > > > > >> I’m confused: do people pay attention to version numbers or not? > > > They pay attention when they go to upgrade. For example when reading NEWS.txt > or CHANGES.txt it is a prerequisite you know what version you are on. Many > users know, while many others don't because it's so easy to figure out > on-the-fly. I don't want to stereotype the user base here. > > As you say we have flexibility with the definition of semver. Since we are an > always-on technology we have the opportunity to define what a significant > breaking change means to us. I believe we can and should use this opportunity > to the benefit of our users, and from experience upgrades are an area where > we can (and need to) make things simpler. We can do this by defining it as a) > the removal of deprecated APIs, and b) dropping backward compatibility with > the previous-previous major. > > If we want to maintain our backward and forward compatibility forever we > should do away with major versions altogether. I'm not in favour of doing > that. It creates significant overhead for both engineers and testing > resources. And it also misses an incentive to push users to stay up to date. > >
