+1 for 6w -- Regards, Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft keyboard sporting it's not-so-smart-assist technology. On Oct 31, 2014 4:07 PM, "Rainer Gerhards" <[email protected]> wrote: > 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. > _______________________________________________ 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.
