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 case.
Cheers, Dmitri. On Mon, Jun 2, 2025 at 11:35 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 takes time on incubation (72 hours vote in the > podling + 72 hours vote in the incubator), we can still do changes on > the main branch without impacting the release currently on vote. > 3. We can create minor version on a release branch if needed (for > instance, we can create 0.9.1, 0.9.2, or 0.10.1 later on the > corresponding branches) > > Today, renovatebot is working on both the main branch and the release > branches: > > https://github.com/apache/polaris/blob/main/.github/renovate.json5#L33 > > I think it would be better to run renovatebot only on the main branch. > The dependencies on the release branches should be updated "on > demand/manually". > > So, I propose to run renovatebot only on main. > > Thoughts ? > > Regards > JB >
