Changes in our dependencies ought to be tracked somewhere more digestible than VCS. Users who use our test framework or have repositories containing custom code intended to run inside of solr will care about changes in deps for both solrj, and core, and whatever components. CHANGES.txt isn't great either, but it's better than nothing. (i.e. https://solr.apache.org/docs/9_7_0/changes/Changes.html#v9.7.0.dependency_upgrades) Ideally an automated dependency upgrade report could exist, but I'm not sure what tool might exist for that.
So I think a Changes.txt entry can be added as a follow on in the case of a direct merge. Simply saying something like we have in the past, just the library and the committer, and the PR/JIRA as applicable. Solrbot's involvement is irrelevant to users, so something like: SOLR-15609: Upgrade log4j to 2.14.1 (hossman) On Thu, Oct 24, 2024 at 10:16 AM Christos Malliaridis < malliari...@apache.org> wrote: > I got a few questions before interacting with the Solrbot PRs, because I > haven't done that before. > > - When are the CHANGES entries added, and when not? Is it just "if Solrbot > created the PR, then it will be added automatically during next release"? > - In case no additional actions are necessary, would I simply merge the PR > via GitHub and look into backporting the changes as usual? > - In case changes are necesasry, would I simply pick up from where Solrbot > left off and continue working on the PR? > - Should any dependency that requires JDK > 11 be backported to 9x? > - And if not, should any older version of the dependency that supports JDK > 11 but is newer to the one in use be "backported" instead? Like minor and > patch versions. > > I'd be happy to tackle the PRs as soon as possible. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
