We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor forever fixed to 0.
But I’m also struggling with how to justify the existence of that unused digit. We have never really done semantic versioning, we’ve arbitrarily flipped the major whenever we felt like “it was the right time” and/or for marketing reasons. Might as well drop the charade, and C*4 seems as good time as any to do that. Perhaps we should discuss this in a separate thread, maybe closer to 4.0 release time, so that it doesn’t distract us from more important current issues. > On 24 Sep 2018, at 17:55, Jeremiah D Jordan <jerem...@datastax.com> wrote: > > So as to not confuse people, even if we never put out a 4.1, I think we > should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our <More > Major>.<Major>.<Patch> versioning of the past never followed semver. > > -Jeremiah > >> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith <bened...@apache.org> >> wrote: >> >> I’d like to propose we don’t do Semver. Back when we did this before, there >> wasn’t any clear distinction between a major and a minor release. They were >> both infrequent, both big, and were treated as majors for EOL'ing support >> for older releases. This must surely have been confusing for users, and I’m >> not sure what we got from it? >> >> Why don’t we keep it simple, and just have major.patch? So we would release >> simply ‘4’ now, and the next feature release would be ‘5'. >> >> >> >> >>> On 24 Sep 2018, at 17:34, Michael Shuler <mich...@pbandjelly.org> wrote: >>> >>> On 9/24/18 7:09 AM, Joshua McKenzie wrote: >>>> I propose we move all new features and improvements to 4.0.x to keep the >>>> surface area of change for the major stable. >>> >>> It occurs to me that we should probably update the version in trunk to >>> 4.0.0, if we're following semantic versions. I suppose this also means >>> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc. >>> >>> -- >>> Michael >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
