2014-10-29 11:46 GMT+01:00 Brian Knox <bk...@digitalocean.com>: > Rainer - for zeromq we break things up into previous stable releases, and > then the "master" of the git repo. We don't allow breaking changes on > master - so I tend to develop against master and even use snapshots of git > master in production projects. It was a bit anxiety inducing at first but > really, it's caused very few problems and bugs are found almost immediately > unless they are really nasty ones. It's been working well. > > Thanks for the feedback. In short (and clearer ;)) words, this sound much like what I have on my mind. It's great to hear it works for 0mq!
Rainer > > > On Wed, Oct 29, 2014 at 6:20 AM, Boylan, James <james.boy...@orbitz.com> > wrote: > > > A lot of how this works depends on how many people are contributing. With > > a lot of active contributors a common practice is to have a release > branch > > and a development branch. It makes it cleaner from a commit history when > > you can squash many commits into a single one to push into the release > > branch. I have mixed feelings about the pros/cons of that process. > > > > Another method I've seen is that there is only one branch and when you > > feel that it has been tested thoroughly enough you merely tag the > 'release > > commit' and generate your release tarfiles off that. > > > > Both of these methods have their positive and negative aspects. A lot of > > it depends on you development cycle and what fits best with your team in > > regards to working more efficiently. > > > > -- James > > --- Sent from my mobile phone --- > > > > ----- Reply message ----- > > From: "Rainer Gerhards" <rgerha...@hq.adiscon.com> > > To: "rsyslog-users" <rsyslog@lists.adiscon.com> > > Subject: [rsyslog] Feedback Request: do we still need -devel versions? > > Date: Wed, Oct 29, 2014 4:47 AM > > > > Hi all, > > > > it may sound strange, but I strongly think about dropping -devel versions > > and instead moving new features directly into the -stable branch. > > > > The reason is that almost nobody nowadays tries out the -devel versions. > > The past two years, I've always seen the same pattern: when I started a > new > > -stable branch, a lot of bug reports immediately appeared - bugs that > > obviously were not detected because nobody used -devel. The really bad > > thing about this is that usually the feature causing the bug was > > implemented some month ago, so I do not have a clear memory what may be > the > > root cause. Also, in a new stable branch there are many changes > intermixed, > > which makes troubleshooting even harder. > > > > As such, I consider a policy change where we will support the current and > > previous stable release (right now that would be 8.4.2 and 8.4.1) and > > enhancements going directly into the -stable release. Actually, we would > > drop the -stable, -devel qualifiers, it would just be "the rsyslog v8 > > release". > > > > Let's consider the next version: changes would go into 8.4.3, but we > would > > still support 8.4.2 in regard to questions. So if someone hits a > regression > > with 8.4.3, he would need to go back to 8.4.2 until 8.4.4 is released. > > > > On the plus side, that would also mean new features would be more readily > > available, in contrast to the 3 to 8 month wait period we currently have > > for those that insist on stable versions. > > > > I am not sure, however, if we should release new versions more rapidly > than > > we did with -stable versions. Technically, it makes sense, but many users > > don't like that (I know from past conversations). > > > > Comments appreciated. > > Rainer > > _______________________________________________ > > 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.
