> well, we don't intend to make backwards incompatible changes :-) What noble intentions...
> 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. :) > 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." > 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). > 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. > On Dec 1, 2014, at 4:48 PM, David Lang <[email protected]> wrote: > > On Mon, 1 Dec 2014, Matt Coleman wrote: > >> I've been on sabbatical and missed the discussion about versioning. I >> browsed through the thread on the mailing list archive, but forgive me if I >> missed anything and mention something that's already been suggested. I think >> the decision to move to a more regular release schedule and simplify source >> control is great. However, I don't think the version numbers should be >> directly tied to the release schedule. >> >> Our organization has adopted Semantic Versioning (www.semver.org). I prefer >> it because your code's version numbers are based on the code, itself, rather >> than an arbitrary schedule; this enables better dependency management. Since >> major versions increment for backwards-incompatible changes and minor >> version increments denote added backwards-compatible features, it allows >> other projects to have 100% reliable dependencies: imagine that "feature X" >> is added to rsyslog, making the version 8.7.0. Due to Semantic Versioning, I >> know that version 9.0.0 will introduce a backwards incompatible change. If I >> write code that uses "feature X", I can safely make it depend on rsyslog >> >=8.7 and <9. > > well, we don't intend to make backwards incompatible changes :-) as such we > will be on 8.100 in a few years. Unless we take the Linus approach and say > that when the minor number gets uncomfortably large we increment the major to > reset it. > > 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 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? > > realistically, a regular release schedule is going to mean that the minor > number is going to jump based on that schedule, so the question is just over > when to change the major number. > > This change is mostly about moving away from the odd/even dev/stable minor > number scheme to a strictly incrementing minor number scheme without explicit > dev releases. We are not setting policies about major number changes. Because > we very seldom remove existing features, major number changes will probably > end up being cases where the internal module API changes in ways that require > module code updates or other similarly drastic changes. > >> Our developers work on feature branches, branched from master. When they >> think it's ready, they notify QA. On a two week cycle, QA selects a set of >> feature branches to target for inclusion in master. They test the features >> individually, then merge them to a temporary branch and run tests to verify >> that the branches didn't have any conflicting changes. If they discover bugs >> in a certain feature that are too complex to be fixed within the release >> cycle, it will be sent back to the developer and pushed back to a later >> release. Tagged commits on the master branch get automatically built and >> uploaded to our package servers. > > This is exactly what is going to be happening with rsyslog. > >> The distinction between development, beta, and production releases is >> handled outside of version control: separate package repositories are used >> to distribute software to the development, beta, and production fleets of >> machines. If a hotfix needs to be made for a production release and new >> development versions have been released, then we branch off of the produ >> ction releases tagged commit, fix the problem in the branch, and tag the >> branch to release it. > > given that we don't have fleets of machines that we are managing, this part > really doesn't apply to us. However, if there is a need for a 'hotfix', that > is what the third number is for. We just doen't expect to need it much based > on past experience. > > David Lang > >>> On Dec 1, 2014, at 1:55 PM, David Lang <[email protected]> wrote: >>> >>> On Mon, 1 Dec 2014, Rainer Gerhards wrote: >>> >>>> Hi folks, >>>> >>>> with the upcoming v8.6.0 release (tomorrow), I thought it would be usefully >>>> to explain the new scheme and kind of summarize our ML discussion. The >>>> preliminary result is here: >>>> >>>> http://www.slideshare.net/rainergerhards1/rsyslog-version-naming-v860 >>>> >>>> Feedback is appreciated. I plan to mention this tomorrow in the release >>>> announcements. >>> >>> Looks good, it may be worth noting other projects that work this way (off >>> the top of my head, linux kernel, firefox, chrome come to mind) as a >>> footnote or something. >>> >>> 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. >> >> _______________________________________________ >> 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. >> > _______________________________________________ > 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. _______________________________________________ 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.
