: 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
