вт, 31 мая 2022 г. в 13:09, William Lallemand <wlallem...@haproxy.com>:
> Hello Ryan, > > On Thu, May 26, 2022 at 01:28:58PM -0500, Ryan O'Hara wrote: > > > > I am the maintainer for all the Red Hat and Fedora packages. Feel free to > > ask questions here on the mailing list or email me directly. > > > > I try to keep Fedora up to date with latest upstream, but once a release > > goes into a specific Fedora release (eg. haproxy-2.4 in Fedora 35) I > don't > > update to haproxy-2.5 in that same release. I have in the past and I get > > angry emails about rebasing to a newer release. I've spoken to Willy > about > > this in the past and we seem to be in agreement on this. > > > > RHEL is different. We almost never rebase to a later major release for > the > > lifetime of RHEL. The one exception was when we added haproxy-1.8 to > RHSCL > > (software collections) in RHEL7 since the base RHEL7 had haproxy-1.5 and > > there were significant features added to the 1.8 release. > > > > I get this complaint often for haproxy in RHEL. Keep in mind that RHEL is > > focused on consistency and stability over a long period of time. I can't > > stress this enough - it is extremely rare to rebase to a new, major > release > > of haproxy (or anything else) in a major RHEL release. For example, RHEL9 > > has haproxy-2.4 and will likely always have that version. > > I understand your point, indeed RHEL is focused on stability and it > seems normal that the packages maintained inside RHEL does not jump from > one major version to another. if nobody minds, I'd suggest IUS approach. haproxy20 = haproxy-2.0 haproxy22 = haproxy-2.2 and so on. end user can install either version. > > > > I do often rebase to newer minor release to pick up bug fixes (eg. > > haproxy-2.4.8 will be updated to haproxy-2.4.17, but very unlikely to > > be anything beyond the latest 2.4 release). I understand this is not > > for everybody. > > > > That's the right way to do it in my opinion, a stable distribution > just needs to follow the minor releases which basically contains the > bugfixes. > > But what we are trying to offer is a way for users to chose another > branch so they could benefits from new features. Since RHEL has a long > life cycle and HAProxy has 2 majors releases per year, RHEL can't > provide them and that's normal. > > Some users actually need up to date versions because the needs evolve, > the tools, and the protocols too. For example someone who want to use > the latest dynamic features with their kubernetes, or who wants to test > http/3. > > Debian had the same problem as RHEL, but it was solved with > haproxy.debian.net which provides multiple HAProxy branches for multiple > debian versions. It would be great if we can achieve something like this > with COPR or anything else. > > > As mentioned elsewhere, COPR is likely the best place for this. It had > been > > awhile since I've used it, but there have been times I did special, > > unsupported builds in COPR for others to use. > > > > Hope this helps. > > > > Ryan > > Thanks! > > -- > William Lallemand > >
