If all metadata fields changed names, it is not back compat is it? 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 > > 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 >> >> 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. >> >> > 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 … >>> > >>> > 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/ >>> > >>> > --------------------------------------------------------------------- >>> > 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.
