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)
We are not setting policies about major number changes.
Since you're reworking the rest of the versioning scheme, why not set the
policy for the major version as well? Having a policy in place would eliminate
an "Is it time to bump the major version?" mailing list discussion in the
future.
<shrug> I just don't think it's a big deal, and I think that the things that
could trigger a major change are unpredictable enough that it's not worth
arguing much about setting a policy.
David Lang
_______________________________________________
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.
