2014-10-31 11:01 GMT+01:00 David Lang <[email protected]>: > On Fri, 31 Oct 2014, Rainer Gerhards wrote: > > 2014-10-31 0:38 GMT+01:00 David Lang <[email protected]>: >> >> On Thu, 30 Oct 2014, Rainer Gerhards wrote: >>> >>> >>> >>>>> +1 for a time-based release approach. >>>>> >>>>> >>>>> I am not sure if David and you talked about the same thing. If I >>>> understood >>>> David correctly (please correct me if I am wrong), he says that we >>>> release >>>> versions (88 to avoid confusion with existing versions), e.g. 88.6.1, >>>> 88.6.2, 88.6.3, 88.6.x whenever they are ready. However, every 6 month >>>> we >>>> would begin a new series, e.g. 88.7.1. From then on, only 88.7 is >>>> updated. >>>> >>>> >>> I'm actually thinking of the kernel model >>> >>> every X months release 88.7, 88.8, 88.9, etc. If there are bugfixes that >>> need to go out between the X month releases, they become 88.7.1 88.7.2 >>> etc. >>> 3-6 months seems to work fairly well for individual projects. In between >>> people can just compile from the master. I don't think we have enough >>> testing participation to go the -rcX route. >>> >>> If there is a major (risky) change, it would justify an 89 release, but >>> that would end up being something like a re-write of the queue model or >>> other very intrusive (and therefor risky) change, not the ongoing >>> features, >>> modules, performance optimizations. >>> >>> >>> mmhh... isn't that -except for the timing- what we do with the current >> -devel/-stable just in other terms? I agree that terms are important but >> should we than name the master branch releases as stable and the monthly >> as >> "old stable". Also, I have the impression that with the kernel almost >> everyone uses the bi-annually releases (in our words the -stable) and not >> the master. >> >> If I am not wrong, that model would probably result in the same problem, >> that is I develop new things in master branch, but everyone begins to >> "test" them when it is rolled into the bi-annually releases. >> > > The releases don't need to be bi-annual, there are advantages to shorter > cycles. > > People do need some stability in what's shipped, so they really aren't > going to be running things from git. So the question is, "how quickly can > you release things without annoying people too much?" > > for the kernel, they are making new releases about every 2.5-3 months. > Firefox is making releases about every 6 weeks. I don't remember what > Chrome's cycle is like, but it's also rapid. > > So how about every 6 weeks for rsyslog? On that cycle, bug reports would still hit me with a relatively fresh idea of what I changed.
Rainer > People are going to start off being afraid of new releases, but they seem > to accept them if they don't have frequent regressions. They also seem far > more afraid of changing major versions than minor versions (and even there, > firefox and chrome are getting people to accept that) > > > Today we have the master tree, -devel releases, -stable releases, and > bugfix releases. > > I'm saying that we would have the master tree, -stable releases, and > occasional bugfix releases (the bugfixes would only fix regressions that > were missed) > > > 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.
