Hi all, I agree with Richard's points. To add my two cents:
It is increasingly important to keep software up to date. The higher velocity required to patch CVEs today (which is a positive development) results in significantly more churn when back-porting compared to the past. I empathize with the time-consuming nature of updating libraries; this empathy is reflected heavily in the 3.0 API. We implemented additional code specifically to ensure the transition from version 2 to 3 is as seamless as possible. We did this because we know maintaining backward APIs is hard. Furthermore, it is typical for projects to EOL two versions back when releasing a major version. This transition often happens even faster for projects with heavy dependencies. If anyone has any issues transitioning off a 1.x build, they can try the dev forums for help - I'm sure they'll find the guidance they need. Best regards, Kristian Rickert On Fri, Jun 19, 2026 at 1:52 PM Richard Zowalla <[email protected]> wrote: > 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. > >
