public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	"DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: Wed, 26 Nov 2025 17:00:26 +0100	[thread overview]
Message-ID: <70b51679-4f18-44e8-9578-e64c79509c40@proxmox.com> (raw)
In-Reply-To: <yhxsxfgzbesxasci72kmtb63ug43lqnth6udeh6kuvkn4uay7z@vnvxstqunfic>

Am 26.11.25 um 13:58 schrieb Gabriel Goller:
> On 25.11.2025 16:53, DERUMIER, Alexandre via pve-devel wrote:
>> Hi, 
>>
>> 10.4.2 has been released last week.
> 
> I don't think so? At least I can't see the tag on github...
> 
>> be carefull with frr updates, from my experience they are always to a
>> lot of bugs && regression when new major version is release,
>> and sometime it take weeks to triggers specific bugs in production.
>> (and even more to debug)
> 
> Yeah, that's exactly why I want to release every minor FRR version
> (while staying one release behind). This approach should minimize
> the impact when a major version is released. The big issue with PVE
> 8.5 was jumping from FRR 8 to 10 -- that's two major versions at
> once, which caused many problems. I believe it's better to do
> frequent small updates where issues are discovered quickly, rather
> than large yearly updates where many problems surface at once.
> 
> What do you think about this?
> 
> That said, I understand your concerns. We've also seen FRR being
> quite unstable lately with many regressions in recent releases. The
> maintainers have told me this should improve going forward.
> 
>> and frr still maintain 10.2 branch for example (10.2.5).
>>
>>
>> Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
>> because I don't have time to retest new version each 6 months.
> 
> Pinning is always possible and something the user can do. Maybe we
> should create a official "guide" or article on how pin in case of
> critical network bugs.
> Obviously the newer features (e.g. fabrics) won't work.
> 
> I don't know how we handle other upstream dependencies that are critical
> yet optional? @Thomas?

We do not have many of those. But in general I agree with releasing
more often and in smaller increments being the better way almost all
of the time.

Version pinning is not something I'd heavily promote, but having an
article/how-to that describes how it could be done and what one needs
to watch out for makes definitively sense, as sometimes it's just the
fastest and simplest stop-gap.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-11-26 16:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 14:13 Gabriel Goller
2025-11-21 14:13 ` [pve-devel] [PATCH frr 1/2] bump frr to 10.4.1, remove obsolete patches Gabriel Goller
2025-11-21 14:13 ` [pve-devel] [PATCH frr 2/2] d/changelog: bump package version Gabriel Goller
2025-11-25 16:53 ` [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1 DERUMIER, Alexandre via pve-devel
2025-11-26 12:59   ` Gabriel Goller
2025-11-26 16:00     ` Thomas Lamprecht [this message]
2025-11-26 17:57 ` [pve-devel] applied: " Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70b51679-4f18-44e8-9578-e64c79509c40@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal