On 9/24/18 12:21 PM, Aleksey Yeshchenko wrote: > 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.
It doesn't have to stay 0. I like your idea of doing meaningful major release number changes. We could also fix our minor version handling behavior. We could use the minor version number to provide meaning for things like upgrade issues, which in the past have been a random <More Major>.<Major>.<Patch> version number, buried in NEWS.txt somewhere. Sometimes people have wished to add new metrics, as an example improvement, and those have been pushed to the next major. This could be 4.1.0: all the 4.0.x bug fixes, along with "your perf monitoring thing may break" messaging to users. Still 4.x, but improvements on 4.0 we're calling 4.1, so beware. I'm totally spitballing here on possible uses of meaningful minors. > 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. Doing this early in the cycle is way better, imo - tests may^Wwill break, third-party things parsing versions may break. Now would be the time to make version changes, instead of waiting until the last minute. Regardless, the OP's statement that new features and improvements should go to 4.0.x seems wrong - shouldn't that be 5.x? (where version numbers could/would be 5.0.x, etc.) Sure, we can create another thread, but since versions break tests and drivers and such, and were all about making sure tests are clean, it's relevant, along with deciding what version to move new feature tickets out to. Michael >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
