Hi, Hoss, I see what you're getting at.
So far we kept it simple and only suggest PRs on main branch, and let committer backport at own discretion. It has a few downsides: * Won't get PRs for deps that are removed in main but still supported in 9x * If we e.g. upgraded main to jetty 11 but wanted 9x to stay on jetty 10, there would not no 10.x.y upgrade PRs Renovate opens separate PR for major ver, but folds patch/minor upgrades into same PR. Thus if we wanted to be conservative for an upcoming release and only do a bugfix upgrade, there may not be a PR for it if a newer minor version exists. Renovate has options for these things, see docs https://docs.renovatebot.com/faq/#renovates-default-behavior-for-majorminor-releases if we want separate bugfix PRs. But if we should have separate PRs for bugfixes and separate PRs for main and branch_9x, then I think the amount would explode somewhat. We currently have a general 5-day delay since a release. Could be we could configure different delays for major/minor/patch, have a look at the documentation site I linked to and see if you believe it is possible. I sometimes get confused by the large amount of configuration options. Jan > 4. apr. 2023 kl. 22:47 skrev Chris Hostetter <hossman_luc...@fucit.org>: > > > : But we don't necessarily need to do it every week, if people feel it is > : noisy. We could disable the bot until we start thinking about a new > : release, and then get a ton of upgrades to merge for the new release. > > That feels like it just pushes all of the work, and risk of discovering > conflicts in dep upgrades, and risk of uncovering bugs, until right before > the release. > > The soon we try upgrades (and the longer we have people & jenkins) > testing out the upgraded deps _before_ the release, the less stress/delay > when it comes time to acctauly cut and RC. > > > As someone who isn't really familiar with the solrbot PRs, the > question/proposal i would make is: > > - Can it "slowly" be "agressive" about upgrade suggestions on 'main' > - aggresive = suggest every possible upgrade to latest possible version > - slowly = wait to suggest until at least X days after new version is > released (in case 3rd party does a bug fix release) > - Can it "quickly" be "conservative" about upgrade suggestions on '9x' > - conservative = only suggest minor upgrades > - quickly = suggest them as soon as they are available > > ? > > Or maybe, to think about the problem differnetly (independent of > solr branch) but w/the same general goals: > > - can it suggest bugfix upgrades (A.M.X -> A.M.Y) ASAP > - can it suggest minor upgrades (A.M.X -> A.N.0) only after some > small number of days delay since last A.N.? release (to wait for a > possible A.N.1 bug fix) > - can it suggest major upgrades (A.M.X -> B.0.0) only after some larger > number of days delay since last last B.?.? release (same reason) > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
