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.
