On Fri, Jun 26, 2020 at 11:32:44AM +0300, Valter Jansons wrote: > On Thu, Jun 25, 2020 at 10:06 PM Jonathan Matthews > <[email protected]> wrote: > > "GA"? It's an open source project! There's no beta product hiding somewhere > > ;-)
:-) > > > > The last 2.2 -dev release was a week ago - here's the announcement: > > https://www.mail-archive.com/[email protected]/msg37687.html > > I am assuming the "2.2 GA version" here means the first 2.2.0 release, > being considered stable and out of -dev. > > On Thu, 25 Jun 2020 at 14:52, Venkat Kandhari -X (khvenkat - INFOSYS > LIMITED at Cisco) <[email protected]> wrote: > > Can someone please let me know when is HAProxy 2.2 GA version planned to > > release ? > > It will be released when it is ready. Generally speaking, the release > schedule for HAProxy is very flexible, and you should not make > expectations around it. Absolutely! We try to approximately stick to a date so that everyone knows that it's time to stop developing and that users can start to test the version without getting too many risks, but there's no point issuing a release if it's going to break for everyone the next week and put users into trouble. We're currently fighting a significant performance regression that William Dauchy spotted on his servers, and I'm very grateful for his patience and his help on this point. It is very difficult to narrow it down but on a very specific workload the CPU usage goes 3-4 times higher than in 2.1. And due to the high traffic it's hard to say whether we're observing a bunch of short-lived looping events or an algorithmic degradation somewhere. And this despite all the indicators and using "perf", "strace", "show *", cores, and usual suspects. While doing so we've found a non-negligible number of medium importance issues that were plaguing this troubleshooting and that were almost all addressed. The CPU usage regression still stands on a very specific workload now. We've found an issue with connection reuse that could grow well beyond the configured maxconn and that could be the root cause, though still uncertain. I plan on issuing a dev11 with all accumulated fixes later today. If we finally fix the problem above, or at least we figure it's extremely specific and shouldn't be a release blocker, we could release during next week I guess. Otherwise I prefer not to expose thousands of users to a behavior that we cannot yet understand. The good point in all this is that 2.2.0 will get even better and more tested than previous dot-zero releases ;-) > If you need to plan ahead for migrations due to any reason, you can > stay on LTS releases and you will have plenty of time for carrying out > such migrations. > Currently, that is either version 1.8 with EOL planned 2022-Q4, or > version 2.0 with EOL planned 2024-Q2. That's exactly the purpose of LTS versions! I'd add that in addition, if there's anything of interest in 2.2 for your deployment you should definitely try it *before* it's released, to make sure any possible bug that would affect you is addressed in time. Cheers, Willy
