вт, 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
> > (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

Reply via email to