I believe that the updates only come once a week, and that it's limited to 5 correct? I actually look forward to seeing "what's new" from Solrbot on Monday morning.
It's also opened my eyes to how many dependencies we have, and I think helps encourage us to look at where we can slim things down. I hope we can learn which libraries are in the "release early/release often" category, and maybe we check for updates much less frequently. I've been very encourage by how SolrBot has worked for us in pushing us to having a more modern codebase. On 2023/04/05 09:56:16 Jan Høydahl wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
