Martin, I don't know if a vote is strictly necessary but it's perfectly fine to do.
Would you like to kick off that VOTE thread? Thanks, Jeff On Wed, Jul 29, 2026 at 3:18 AM Martin Wiesner <[email protected]> wrote: > > Hi Jeff, > > Thanks for the summary. I‘m absolutely fine (+1.5) with EOL of 1.x and > announcing it via news entry on the project‘s website. > > Personally speaking and given our current capacity, I see 2.x as LTS, as > we‘re quickly heading towards 3.0.0 this year. > > What we should support / motivate external projects: > Migrate to at least 2.5.x, that includes using UD-based models instead of SF > ones. > > Maybe Kristians idea to blog about the project‘s new features and/changes > could be helpful in that context too. > > Ideally, we‘d have a vote for the EOL of 1.x, so it has a binding character. > But don’t know if it is strictly necessary. If you can trigger it, I‘d be > happy. If lazy consensus is preferred: I‘m okay with it. > > Best > Martin > > > > > Am 28.07.2026 um 21:53 schrieb Jeff Zemerick <[email protected]>: > > > > 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. > >>>>>> > >>>>>> > >>>> > >>
