> 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.
Almost. They come every Sunday, are limited to 10 new each hour and a total of 30 concurrent open PRs. See https://github.com/apache/solr/blob/main/.github/renovate.json#L49-L50 Right now there are 2 open, so in practice we get every single dep upgrade since last week. I am also thrilled about the side-effect it has had to inspect our codebase and ask questions like "why do we need dep X" and slim things down. It would be interesting to also have some insight into which of our direct and transitive dependencies are "stale", i.e. not updated in years. I did a quick checkout of 9.0 tag and compared versions.lock with main. Here are the dependencies that are still on the same version in main (excluding test-dependencies): https://paste.apache.org/qfqvf Could be a great list to walk through, and create JIRAs to deprecate, upgrade or remove our "direct" dependencies that rely on these old versions. Jan > 5. apr. 2023 kl. 12:21 skrev Eric Pugh <ep...@apache.org>: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
