Thank you, Eric. Tika is used both as a library and a service. I'm not sure there's a huge difference between breaking an API vs. breaking configuration and an endpoint's behavior. Moving to 4.x will take some effort, I acknowledge.
I'm worried about the futility of claiming 5 years when, by then, a bunch of our dependencies will have moved to > Java 11, and we won't be getting _their_ security fixes in our 3.x branch. How about we propose 18 months for maintenance and security? What do others think? On Wed, Aug 19, 2026 at 8:03 AM Eric Pugh <[email protected]> wrote: > > I know we want to all EOL the last version, but in this time of CVEs etc, > having short EOL is tough. > > What would prevent someone using 3 from moving to 4? The reason I ask is that > if you are moving faster to EOL than your downstream customers are updating > and releasing, then you can put the in a tough spot. Obviously, this is > more prevalent for libraries than server code. > > A case in point.. Solr 9 runs on Java 11. Solr 10 runs on Java 17 and > later (and maybe even newer Java)…. Solr 9 has a large installed base. Solr > leans on OpenNLP as a library, and in Solr 9 it uses OpenNLP 1, which also > shares java 11. OpenNLP moves in 2.0 to using newer versions of Java, which > means we can’t upgrade Solr 9 to using OpenNLP 2…. Yet folks will be using > Solr 9 for years more before they move to Solr 10 (or even jump to 11 or > 12!). So now we are faced with, do we accept the various CVE’s etc that > impact OpenNLP 1, or do we rip it out….. Which is a breaking change for > Solr 9 users and leaves them with a less functional Solr. > > In the case of Tika, we actually kind of had the same thing.. Yes, Solr has > been on Tika 1 for a long time, and so the pile of CVE’s etc meant that in > Solr 9.10 we actually made the breaking change of making Tika accessible from > Solr not as a library but as a separate server app, basically because the > effort to upgrade from Tika 1 to Tika 3 as an embedded app was too much, > especially in a minor version release. It was…. Not ideal…. And a lot of > work…. To say the least! > > > Maybe my tl;dr is to decide “Is Tika library that gets embedded or a server > app that gets deployed”….. If it’s a server app, then I still think you > should think about not EOL’ing for a an extended time, say 18 to 24 months. > And if it’s a library, then 5 years? These time frames are based on the > idea that lots of folks build an app, and then ship it, and it just does what > it does in production for a long time. And that forced upgrades are not what > folks want. > > > > > On Aug 19, 2026, at 7:16 AM, Tim Allison <[email protected]> wrote: > > > > All, > > What do we want to set the EOL for 3.x to be? The migration to 4.x > > is quite a step, and I want to give people time. > > At one point, I think we were thinking 6 months after the release of 4.0.0. > > A year feels somewhat too long to me... 9 months (May 2027)? > > > > wdyt? > > > > Cheers, > > > > Tim > > > > 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.
