Fair question…. So in digging more, the names changed between Tika 1 and Tika 3, so we may have already caused that…
I dug more into it, and there may be some mapping from Tika 4 back to Tika 3 that we could do. Though it also might just be one of those “we can try for backcompat, but YMMV” and therefore we shouldn’t try it.. I pushed up a potential fix. I’m also okay with saying Tika 4 is on Solr 11, and Tika 3 is on Solr 10. I don’t anticipate many or any releases of Tika 3, so that means for Solr 10 we won’t get lots of updates that need applying. And we can apply Tika 4 on main easily with the current Solrbot process as various Tika 4’s come out. > On Sep 14, 2026, at 11:24 AM, Jan Høydahl <[email protected]> wrote: > > If all metadata fields changed names, it is not back compat is it? > https://github.com/apache/solr/pull/4853#discussion_r3929085061 > <https://github.com/apache/solr/pull/4853#discussion_r3929085061> > > Jan Høydahl > > > 14. sep. 2026 kl. 16:36 skrev Eric Pugh <[email protected]>: > > > > We are down to just one open PR! From 20! > > > > At first I thought the upgrade from Tika 3 to Tika 4 was this impossible > > thing, that required us to totally re-imagine how we work with a tool like > > Tika. And while there is a big opportunity to do just that, it turns out > > our existing integration works just fine…. > > > > https://github.com/apache/solr/pull/4853 > > <https://github.com/apache/solr/pull/4853> > > > > It would be good if some other folks could test out this update and confirm > > that the backwards compatible claim does continue…. > > > > Eric > > > > <4853.png> > > > >> On Sep 3, 2026, at 3:20 PM, Eric Pugh <[email protected]> > >> wrote: > >> > >> Okay, it seems like we are ending more at “lets not worry about perfect > >> change log on these Solrbot PR’s”… > >> > >> > >> We are down to six open PR’s from 20: > >> https://github.com/apache/solr/pulls/solrbot > >> <https://github.com/apache/solr/pulls/solrbot> > >> > >> I’ve tagged some folks on various PR’s where I was hoping to get a second > >> opinion on some things. > >> > >> The only really “insurmountable” one right now is the Tika 3 to 4 > >> upgrade…. Tika 4 is wildly different than Tika 3,2,1, and so if we want to > >> move to that, it’s more then a version bumps, it a rethinking of our > >> extraction module. See https://github.com/apache/solr/pull/4853 > >> <https://github.com/apache/solr/pull/4853>. > >> > >> > Tika 3→4 isn't "same parsers, new API polish" — it's a shift from an > >> > in-process, XML-configured, XHTML-emitting library toward a > >> > process-isolated, JSON-configured, Markdown-emitting, LLM-aware pipeline > >> > runtime. That's consistent with what you're seeing — it really does work > >> > differently, and a straight dependency bump (like the "barebones > >> > implementation, stays with XML" approach in your PR#4853 branch) is > >> > reasonable as a first step, but won't get you any of the > >> > process-isolation or VLM benefits without deeper integration work. > >> > >> > >> <4853.png> > >> > >>> On Sep 2, 2026, at 2:12 PM, Jan Høydahl <[email protected]> wrote: > >>> > >>> Hoss, > >>> > >>> The strategy of your proposal Hoss has crossed my mind as well. > >>> And if we are to keep automation, and keep the dep-upgrades section, > >>> this is I think one way forward. Currenlty the file name and title is > >>> pulled > >>> from the PR title, but for this new approach to work it must be pulled > >>> from > >>> the diff of libs.versions.toml I think. > >>> > >>> Happy to hear other thoughts too. > >>> > >>> Jan > >>> > >>> > 2. sep. 2026 kl. 00:53 skrev Chris Hostetter <[email protected]>: > >>> > > >>> > > >>> > > >>> > : Okay, so how do we want to handle changelog entries for these from > >>> > : Solrbot? I want to draw attention to this conversation: > >>> > : https://github.com/apache/solr/pull/4842#pullrequestreview-5077496282 > >>> > <https://github.com/apache/solr/pull/4842#pullrequestreview-5077496282> > >>> > … > >>> > > >>> > Strawman proposal from someone who doesn't really know how solrbot > >>> > works... > >>> > > >>> > 1) Change it to stop putting the PR# and and version details in the > >>> > changelog/unreleased/ file *name* > >>> > > >>> > 2) It should just create file names like > >>> > "dep-update__google-errorprone.yaml" (that match the version key in > >>> > libs.versions.toml) > >>> > > >>> > 3) if a file with the same name already exists in changelog/unreleased/ > >>> > , > >>> > it should just overwrite it completely. > >>> > > >>> > 4) if it updates 50 deps in a single PR, there should be 50 files > >>> > created > >>> > in changelog/unreleased/ > >>> > > >>> > 5) humans doing manual dependency updates should follow the same > >>> > practice > >>> > > >>> > > >>> > ...in theory, this leaves us with a situation where automated changelog > >>> > generation "just works" in terms of ensuring that we get a clean > >>> > "Dependency Upgrades" section that lists every dependency that was > >>> > upgraded since the last release -- but each dependency is listed no > >>> > more > >>> > then once, listing the "latest" version it was upgraded to. > >>> > > >>> > > >>> > If we don't feel like *every* dependency is worthy of having it's > >>> > upgrad > >>> > mentioned in the changelog, then there should be some way to annotate > >>> > the > >>> > "important" dependencies (so both humans & solrbot can tell which ones > >>> > are > >>> > worth documenting) and precommit should fail if a file in > >>> > changelog/unreleased/ exists named after a non-important dependency. > >>> > > >>> > > >>> > is that viable ? > >>> > > >>> > > >>> > > >>> > -Hoss > >>> > http://www.lucidworks.com/ <http://www.lucidworks.com> > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: [email protected] > >>> > For additional commands, e-mail: [email protected] > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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. 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.
