Hi David, On Tue, Feb 08, 2011 at 05:24:10PM +0900, David Cournapeau wrote: > Hi, > > I understand that the master branch on the official git repository is > labeled as unstable, but I was wondering to what degree it is > considered unstable by haproxy developers ? Is it unstable as "you > would be crazy to use this in production", or are some people using it > in production ?
It is the second one. A few sites are running it in production, but I know them, have already reviewed their configs and can inform them when I fix something that might affect them. These sites also cooperate by easily reporting strange issues, providing logs or are willing to debug on live traffic when needed. In fact they're working as beta-testers in a very well defined perimeter. I'm sure there are other adventurers running it without me being aware of it, but it's their problem if it breaks ;-) > For example, when I read the changelog for 1.5dev3 on > haproxy page, it seems that some people are using some features not in > 1.4.9. Yes indeed. Some are also using a few backported features, such as the support for the PROXY protocol. To be honnest, I wouldn't recommend running 1.5-dev if you don't know what to expect from it nor if you're willing to be very open about your config, logs, or accept some emergency updates. But if you're OK with all of that and want some 1.5 features, there is almost no risk. In fact, most of the bugs I recently discovered in 1.5 were also in 1.4, so there are very few regressions. Sometimes, the config can change a bit between two consecutive development versions but that should not cause particular trouble. > As a tangential question, is there a roadmap for 1.5 ? Yes, it's in the ROADMAP file in the sources. It says that 1.5 is deemed for end of 2010. As you might have noticed, it's been delayed a lot, and many important features have still not been implemented. I really want to implement basic server-side keepalive before releasing it, as well as POST parameter extraction, the "return" statement and possibly the "use-server" if possible. The other ones have less impact and can be brought into maintenance releases. The server-side keep-alive is really the hard part because it has revealed many remaining internal mis-designs that must be addressed before releasing. Regards, Willy
