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
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
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,