2014-12-02 0:41 GMT+01:00 David Lang <[email protected]>: > On Mon, 1 Dec 2014, Matt Coleman wrote: > > well, we don't intend to make backwards incompatible changes :-) >>> >> > What noble intentions... >> > > The only backwards incompatible changes that I know of that we've > deliberatly made since I started using rsyslog in the 3.x days is the > dropping of the BSD config language and the changes to the module interface > for 8.x > > >> as such we will be on 8.100 in a few years >>> >> > What's wrong with that? Numbers have this great feature: they can be as >> big as we need! Besides, the same concern applies to 6 week incrementing >> plan, it would just take quite a few years. :) >> > > people (and systems) have some trouble with the idea that 1.100.1 is > larger than 1.9.1. Since it's not a simple number they do an alpha sort and > get the wrong answer. > > That said, I think such systems are broken and people should learn, so I > don't have a problem with the minor number being large. > > Unless we take the Linus approach and say that when the minor number gets >>> uncomfortably large we increment the major to reset it. >>> >> > This undermines the main benefit of Semantic Versioning: "I know this >> version of the dependency will break my software." >> > > I don't think that semantic versioning is really that useful. There are > far more cases where bugs caus incompatibility than deliberate > incompatibilities. > > Or looking at it another way, if there are backwards incompatible >>> changes, how many do there need to be to cause a major version change? >>> >> If there are backwards incompatible changes in a release cycle, that >> cycle's version number has the major version incremented (not once per >> backwards-incompatible change). >> >> if there are 5 features out of 1000 dropped over a few release cycles, >>> should that cause the major version to jump by 5, especially if they are >>> minor features >>> >> If those 5 features were dropped over 5 release cycles, then there would >> be 5 major version increases. "Minor" features may be minor in your usage, >> yet core to someone else's work. No one seems to have a problem with >> Chrome's major version being 39 (or Firefox's 34). >> > > The problem with changing the major number is that for some reason, distro > maintainers are terrified of new major numbers, no matter what the reason, > and will frequently stick with old major numbers for a long time. See how > rsyslog 4.x and 6.x were basically skipped by the distros entirely, and 7,x > came within a couple months of being skipped as well (8.x was very near > it's stable release when the first distros shipped a 7.x version) >
I think this (unfortunately) is not just a technical discussion. Technically, I agree for the most part with Matt. I don't agree any minor change must bumb the major version, e.g. I am about to remove a command line option (-u) that more or less nobody used but me, so does that really justify moving to v9? If thinking purely technical, the right answer may be "yes". But, as David said, there are a lot of human/political implications with version numbers. I started by doing major number increments when kind of compatibility issues occurred (but less strictly given than you state). The end result is what David explains: it was exceptionally hard to get distros pick up those releases. So IMHO and IME (!) the major version number is primarily a political tool. Actually, I intend to keep v8 for quite a while from now on. If we are honest, we could even agree that the simple one-number version number being incremented that systemd is doing is exactly the right thing to today's environment (esepcially politically). And looking a bit deeper, this is more or less what rsyslog will also use from now on, almost all future releases will be 8.x.0 where x is a single incrementing number, based on time. Note that Ubuntus YY.MM version scheme is also exactly following the same metaphor, just hidden in a diffrent way. IME this actually is what people want, no matter how bad it technically is. But it's probably very policitcally incorrect to state it that bluntly ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
