Based on the previous messages and the thread's feedback, I propose that we immediately EOL 1.x and not do another 1.x release.
I am moving this forward under the lazy consensus model. If there are no objections within the next 72 hours, this proposal will be considered approved, and we will move forward as described above. If you have valid technical concerns or feel we need a formal vote instead, please reply to this thread with your reasoning. Thanks, Jeff On Tue, Jul 28, 2026 at 3:28 PM Richard Zowalla <[email protected]> wrote: > > 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. > >>>> > >>>> > >> >
