Hi Jeff, Yes - I think is basically the current summarization. You didn’t miss anything.
(We have a CVE published with the last releases, which is also applicable for 1.x - so if LTS is on the table, it needs to get another release) Gruß Richard > Am 28.07.2026 um 21:23 schrieb Jeff Zemerick <[email protected]>: > > Hi all, > > It's been almost 3 weeks since the last message on this thread. I > think it's worth picking up and acting on. > > To summarize the discussion up to this point: > > * I see a few folks did a "+1" to the option A with a short grace > period, which we might could argue has already come and passed. > * Eric mentioned an LTS version that won't get new features but will > get security updates. > * Richard reframed it as a capacity problem and that OpenNLP has a > small team it's difficult to stay on top of older releases. > > Did I capture those points accurately? Did I miss any perspectives? > > Thanks, > Jeff > > > On Wed, Jul 8, 2026 at 9:29 AM Martin Wiesner <[email protected]> wrote: >> >> Hi all, >> >> any other opinions / perspectives from the committers / PMC members? >> I’d like to encourage everyone to participate in this important discussion. >> >> Please share those within the next 1 or 2 weeks so we can find a consensus >> and come to a decision. >> >> Best >> Martin >> -- >> >>> Am 20.06.2026 um 12:38 schrieb Kristian Rickert <[email protected]>: >>> >>> 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. >>>> >>>> >>
