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.
