18 months is a nice number On Mon, Aug 24, 2026, 8:58 AM Tim Allison <[email protected]> wrote:
> 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. >
