Haproxy branch support lifetime

Hello,

I’d like to get some clarification on the lifetime support for branches. I’m currently using branch 1.9 and would like to know when HAProxy will stop maintaining this version.

I found this resource which states LTS branches are supported for “Current Version - 3 years” and all other releases are “Current Version - 18 Months”. Does this apply to the community version of HAProxy or is this for Enterprise customers only? If it does apply to the community version, do we take the initial release of the branch and add 3 years/18 months? Branch 1.9 was released 10 months ago and is not a LTS release. Does that imply it only has 8 months of maintenance left?

If those support lifetimes don’t apply to the community version, where can I find a rough timeline of support?

Thank you

Please do not use the Site Feedback category for question regarding Haproxy. It is for issues related to this website/forum, not haproxy.

This is for HAPEE and ALOHA, both of which are commercial products.

Neither HAPEE nor ALOHA is equivalent to haproxy.

Please use haproxy.org for your research, not haproxy.com - the former is the OSS project and the later is a commercial offering. The former also lists all haproxy release branches and its support status.

Haproxy (the OSS project) does not have fixed support time tables (just like Debian). Instead, whether we keep supporting a specific release branch depends on it’s usage.

An example, the 1.5 branch, first released (stable) in June 2014, more than 5 years ago, is still in “Critical Fixes only” support mode, and only now we are thinking about sunsetting 1.5 support.

No, it does not. A lot of people use 1.9 and I imagine we are going to continue to support it for some time. The fact that 1.9 isn’t a LTS release does not mean support is capped at 12 months (there are no fixed time tables).

Maybe @willy would like to elaborate exactly what we can expect from LTS vs non-LTS branches in terms of support, its probably buried somewhere in the mailing list but I was unable to find right now.

Hi Lukas,

thanks for bringing me in

Yes, non-LTS branches were made mainly for early adopters and averagely higher skilled users (i.e. those who build from sources and can perform a rollback by themselves in case of trouble). Having this benefits both users and developers:

  • users get new features earlier
  • developers get feedback earlier, usually with more detailed bug reports

I initially announced for 1.9 that the goal was to have no more than 18 months of maintenance. Ideally for future non-LTS like 2.1 I’d like to shrink this a bit because by the time a new non-LTS is emitted, the previous LTS is supposed to have reached as good a stability level as the previous non-LTS given that the core changes are quite limited. Thus 1 year plus a few weeks should be enough to allow early adopters to switch and always have the choice between two recent versions among which one is LTS and one has stabilized for at least 6 months.

For 1.9 and 2.0 we’ve seen a tremendous amount of breakage, in part due to the fact that we didn’t enable HTX by default in 1.9, leaving some code paths little tested, so some reports were delayed post-2.0. With this said, all the bugs that affect 2.0 also affect 1.9 at the moment so it cannot even be argued that 1.9 is more solid than 2.0, it’s just that the different defaults make them less visible with the same configuration. In addition there are definitely some bugs that we won’t be able to fix in 1.9 without taking the risk to break much more, so I’d say that by design and original intent, this version has a limited lifetime. It can be seen as a maintained preview in some sort :slight_smile:

This doesn’t mean we’ll leave all users in the dust past one point. But as time passes, we must encourage reporters of issues on 1.9 to verify if 2.0 still has the same issue, and if not, then to upgrade. Very quickly we’ll reach the point where no user has any valid reason to stick to 1.9. So the goal indeed is to see 1.9 support quickly fade away in favor of 2.1, 2.0, 1.8 and so on. With the state of current bug reports I already don’t see a good reason for users not to switch from 1.9 to 2.0 by the end of this year instead of updating to the next 1.9 (I’m not counting 1.8 and older in this). In the very worst case it should be “just” a matter of changing default settings (disabling htx, pools, threads) and they’d basically have 1.9. And to be honest, without pools and htx, one could ask why not to stay on 1.8 then :slight_smile:

In any case 1.9 will not disappear without a long prior notification on the mailing list (and possibly some debates there). Maybe we should mention this in “haproxy -v” by the way.

Hoping this helps,
Willy

Yes, I like the idea of mentioning whether or nor we are on LTS in the haproxy -v [-vv] output.

Maybe since such versions are expected to be short-lived, we have an approximate idea of their end date. So it could be possible to indicate in the output something like “end of support expected around Q1 2020, check haproxy.org for updates”. This can definitely help with components that people rarely upgrade and sometimes discover in field (or have forgotten about). And for LTS releases, we can indicate something along “this version is long term supported, which means that bug fixes will be provided several years after the initial release, please visit haproxy.org to verify you’re up to date” (we can maybe link to the current version’s known bugs list by the way).

1 Like

Thank you both for the detailed answers. They have addressed my question.

My original intention for labeling this issue as Site Feedback was because I couldn’t find much of this information on the site. I like Willy’s recommendation of adding those short snippets to either the haproxy -v output or somewhere on the site.