+1, Agree with running this only on main
On Mon, Jun 2, 2025 at 11:22 AM Eric Maynard
wrote:
> +1, great idea. This process change will reduce noise in the repo as we add
> more releases, and it also aligns more closely with the idea of a release
> as a stable snapshot of the code at some point
+1, great idea. This process change will reduce noise in the repo as we add
more releases, and it also aligns more closely with the idea of a release
as a stable snapshot of the code at some point in time -- including the
dependencies as they were at that time.
--EM
On Mon, Jun 2, 2025 at 9:14 A
Hi JB,
I agree that it doesn't feel safe to run Renovate on release branches
and risk dependency upgrades between release attempts. Besides, we can
always bump versions manually if needed.
So, +1 on your proposal to only run Renovate on main.
Thanks,
Alex
On Mon, Jun 2, 2025 at 5:58 PM Dmitri B
This model for release branches makes sense to me.
I also support NOT running Renovate on release branches. If we need to
include dependency upgrades in another RC, I suppose we can redo the
release branch from main (or manually apply version changes)... however,
I'd expect this to be a very rare
Hi folks,
Today, when we do a major release (0.9.x, 0.10.x, ...), we create a
release branch.
Then, we do RCs on these release branches.
The three main reasons for that are:
1. We can create several RCs from a release branch (and it happens
often especially during incubation)
2. As a release vote
