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. 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. 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. > 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.
