note: that PR dependency changelog removal PR did land and our 9.11 Changelog doesn't mention dependencies. There is one open for main (intended to apply to 10x): https://github.com/apache/solr/pull/4944
On Thu, Sep 10, 2026 at 9:45 AM David Smiley <[email protected]> wrote: > > Only two of those listed use-cases could be answered by the changelog. Most > weren't *change* oriented but the changelog is about changes. This > reinforces to me that we should do what I proposed -- DROP the solrbot driven > changes. Don't burden the RM with deriving a list of all dependencies that > *changed*. If someone *really* wants to know... I would advise them not to > trust our changelog for such a thing anyway -- not unless we have an > automated solution. > > And you had non-changelog answers for the *change* ones: > > “I am aware of this CVE in this dependency of Solr, did it get fixed” —> > > Consult our VEX entries for that dependency and the version of Solr > > concerned. > > “I use a specific module of Solr, what does that drag along”. —> Maybe an > > SBOM for Solr itself? > > > On Thu, Sep 10, 2026 at 7:45 AM Eric Pugh <[email protected]> > wrote: >> >> I lean towards the manual (AI assisted) cleanup approach. There are too >> many people working across a long release cycle with differing opinions on >> what is changelog worthy to get it to an automated process that drives a lot >> of value. >> >> I am also wondering more and more if the changelog is the right way to >> convey dependency changes? It really quickly becomes a big list of many >> unknown libraries. I think we need to look at it more from “What do people >> want to know” in order to understand best way to answer it. For example: >> >> “I use SolrJ, what do I need to do to upgrade to the next version”. —> List >> of SolrJ required dependencies in the Ref Guide. >> >> “I use Solr slim bistro, I really care about specific changes”. —> Maybe we >> should be using a SBOM for this use case? “This is what we actually ship in >> Solr binary”. >> >> “I use a specific module of Solr, what does that drag along”. —> Maybe an >> SBOM for Solr itself? >> >> “I am aware of this CVE in this dependency of Solr, did it get fixed” —> >> Consult our VEX entries for that dependency and the version of Solr >> concerned. >> >> >> >> >> > On Sep 10, 2026, at 2:49 AM, Jan Høydahl <[email protected]> wrote: >> > >> > Thanks for bringing it to the list, we already started discussing this >> > topic on some solrbot PRs. >> > >> > Surprised the wizard still proposes a py script, as it would be >> > duplicating entries already filed by solrbot on each patch. >> > And you are correct that, when so much time passes between releases, there >> > will be solrbot duplicates, or triple or quadruple entries for the same >> > dependency. >> > >> > A better process is needed, but may I suggest a manual (AI assisted) >> > cleanup for the upcoming release, where you prune duplicates and fix >> > nonsense titles like the below example. Like back when we had CHANGES.txt >> > I always fixed it up, removing duplicates or dead meat, rewriting some >> > entries etc. >> > >> > Then this thread may hopefully decide an improved process going forward. >> > Good point though on the shipped vs non-shipped distinction, a test-only >> > or build-only dependency is obviously not that interesting for a changelog. >> > >> > Jan >> > >> > > 10. sep. 2026 kl. 04:10 skrev David Smiley <[email protected]>: >> > > >> > > Not only does that script generate a bunch of changelog yaml, but we >> > > already have lots of existing ones. I wish to remove them: >> > > https://github.com/apache/solr/pull/4895 >> > > <https://github.com/apache/solr/pull/4895> >> > > >> > > On Wed, Sep 9, 2026 at 9:59 PM David Smiley <[email protected]> wrote: >> > > >> > >> (I'm writing this in the context of being the release manager for 9.11) >> > >> >> > >> It's unclear how I should handle changelogs for dependencies. If I >> > >> blindly follow the release wizard like a robot, it runs: >> > >> python3 -u dev-tools/scripts/addDepsToChanges.py --user solrbot >> > >> --version 9.11.0 >> > >> Which in turn uses "git log" to find all commits by "solrbot" and >> > >> converts >> > >> that commit to a yaml entry. After lots of months, there are *many* yaml >> > >> files. Many look expected / boring. But then there are some interesting >> > >> entries such as the following: >> > >> >> > >> title: Update all non-major dependencies >> > >>> type: dependency_update >> > >>> authors: >> > >>> - name: solrbot >> > >>> links: >> > >>> - name: PR#4597 >> > >>> url: https://github.com/apache/solr/pull/4597 >> > >>> <https://github.com/apache/solr/pull/4597> >> > >>> >> > >> >> > >> I *love* that it was one PR for many dependencies instead of a shotgun >> > >> of >> > >> commits! But it doesn't even say what it updated exactly; sigh. Imaging >> > >> searching git log message to find an update and not getting a hit here; >> > >> ouch! An earlier bulk dependency update at least had a detailed commit >> > >> message. Now consider that there are other many other solrbot individual >> > >> updates... which begs the question: how is this to be mixed with those? >> > >> If I ignore this problem as RM, we have a mismash of partial >> > >> information. >> > >> >> > >> I propose dropping "solrbot" authored changelog entries entirely. Drop >> > >> this step in the release wizard, drop that python script. The changelog >> > >> *does* have dependency updates that were interesting enough to be done >> > >> by >> > >> (or on behalf of) a named human. >> > >> >> > >> I'm in favor of someday maybe adding a single changelog entry per >> > >> release >> > >> with a compact list of dependencies that were updated, filtered to those >> > >> that we actually ship in a binary distribution. But IMO not a priority. >> > >> >> > >> ~ David Smiley >> > >> Apache Lucene/Solr Search Developer >> > >> http://www.linkedin.com/in/davidwsmiley >> > >> <http://www.linkedin.com/in/davidwsmiley> >> > >> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> Disclaimer >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived by Mimecast, a leader in email security and cyber >> resilience. Mimecast integrates email defenses with brand protection, >> security awareness training, web security, compliance and other essential >> capabilities. Mimecast helps protect large and small organizations from >> malicious activity, human error and technology failure; and to lead the >> movement toward building a more resilient world. To find out more, visit our >> website. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
