In contrast to Solr, the OpenNLP community is very small, and backporting and maintaining different branches (3.x, 2.x, 1.x) is time consuming and honestly not much fun, unless you happen to have a day job that actually needs it.
So from my POV this is really a volunteer-capacity question. Also for reviewing, testing and producing an actual release. If someone is willing to step up and do the work: fine. And consumers who still need 1.9.x are free to fork it, or take a patch-based approach (like it can be done via the TomEE patch plugin) to update the jars in place, especially if this is solely about satisfying CVE scanners and similar. We’ve been running an EOL policy in Apache TomEE for quite a while now, and so do Apache Storm and Apache Tomcat. I don't think maintaining versions endlessly is a good thing (at least from a volunteer capacity side of things; you can still wrap around a business model . What happens when the next transitive CVE shows up in a lib that itself is no longer patched? From my experience, that just gets cumbersome. We had that scenario in TomEE 9.x once Tomcat 10.0.x went EOL pretty fast; so I was back porting Tomcat patches and patching inline for quite a few months (wasn’t fun at all). In a perfect world with lots of people willing to do the work: fine. But that doesn't apply to the current OpenNLP community IMHO, or at least not yet. Richard > Am 19.06.2026 um 16:14 schrieb Eric Pugh <[email protected]>: > > I am not a committer, but I’d leave towards leaving it open ended if the > tooling to produce a release remains working. > > I think EOL is very important to convey “hey, we no longer can produce a > release” or “we no longer have the in house knowledge to maintain this”, but > if the release process is still manageable, and people aren’t trying to jam > in NEW FEATURES into 1.x, then I don’t see why you need to close it off. > > I am very appreciative of the 1.9.5 coming out, and I would hope that if more > CVE’s pop up, being able to publish a 1.9.6 would be great. > > > What if, and this is just an idea, you reframed things? Instead of talking > about EOL, what if you talked about LTS: Long Term Support. > > 1.9 is our LTS. If a CVE pops up, you can expect a 1.9.6 or 1.9.7. There > will never be a 1.10 with new features. All new features will go to OpenNLP > 3. We reserve the right to decide when 1.9 line is no longer LTS. > > > My experience in Solr is that there is a HUGE set of people who are happy > with their specific solution, and won’t ever upgrade till there is a big > event. For them, knowing they are on a LTS version, and knowing that it can > be produced reasonably easily, seems like a win-win for everyone. When 1.9.x > becomes a pain to release, then call the LTS period “done”. > > I wrote down some specifics that I haven’t actually shared with the Solr > community yet, but here you go: > https://docs.google.com/document/d/17qJIfbSoRYvwrPt5OWjqmliwghflDzV9fA0XmXmNSBE/edit?usp=sharing > > Eric > > >> On Jun 18, 2026, at 12:39 PM, Kristian Rickert <[email protected]> wrote: >> >> a) +1 >> b) I'd lean on a short grace period. >> >> >> On Wed, Jun 17, 2026 at 11:52 PM Richard Zowalla <[email protected]> >> wrote: >> >>> a) +1 >>> b) b2/b3 (if other CVEs are approaching) >>> >>> Examples: https://tomcat.apache.org/tomcat-9.0.x-eos.html >>> <https://tomcat.apache.org/tomcat-9.0.x-eos.html> >>> >>>> Am 18.06.2026 um 05:23 schrieb Martin Wiesner <[email protected]>: >>>> >>>> Hi all, >>>> >>>> given recent security fixes that landed in OpenNLP's main branch and the >>> request for back porting these changes to the very oldskoolish 1.9.x line >>> [1], the people involved noticed that the efforts to maintain three >>> separate version lines along the road were pretty high and resource >>> consuming. >>>> >>>> Therefore, I'd like to propose to (finally) declare Apache OpenNLP 1.9.x >>> EOL publicly via a News announcement on the project's website. >>>> >>>> Primary questions: >>>> (a) Do we have consensus that such an EOL announcement is long overdue >>> and should be put out rather soonish? >>>> (b) Time of the announcement: Options that I see: >>>> - b1: Directly with the projected release of the 1.9.5, marking it as >>> the last release ever to be expected for OpenNLP 1.x. >>>> - b2: Shortly after - with a grace period - for instance End of July >>> 2026, or similar short ranged targets. >>>> - b3: End of year 2026, that is Dec 31, 2026 >>>> (c) Are there any requirements by the ASF to put out an EOL >>> announcement? Jeff, do you have infos about it? >>>> >>>> Open for others to add thoughts and related aspects to this discussion. >>>> Please share your opinions and provide (your) answers to question (a) to >>> (c). >>>> >>>> Best >>>> Martin | mawiesne >>>> -- >>>> [1] https://lists.apache.org/thread/nvzl4g2b6rc149nf54xpnorjso5h0mlp >>>> <https://lists.apache.org/thread/nvzl4g2b6rc149nf54xpnorjso5h0mlp> >>> > > 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.
