You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by Tim Allison <ta...@apache.org> on 2026/08/19 11:16:51 UTC
EOL for 3.x?
All,
What do we want to set the EOL for 3.x to be? The migration to 4.x
is quite a step, and I want to give people time.
At one point, I think we were thinking 6 months after the release of 4.0.0.
A year feels somewhat too long to me... 9 months (May 2027)?
wdyt?
Cheers,
Tim
Re: Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Nicholas DiPiazza <ni...@gmail.com>.
I see no better way
+1
On Mon, Oct 19, 2026, 2:57 PM Nick Burch <ni...@apache.org> wrote:
> On Mon, 19 Oct 2026, Tim Allison wrote:
> > I think the only safe way forward is to require jre 17 in tika 3.x's
> > tika-server and tika-server-standard. This would be on the next minor
> > release, say 3.4.0.
>
> I would prefer not to bump the JRE version without a major release, but I
> can't see any easy way to avoid that since we've already moved new
> development onto 4.x with a pile of other changes
>
> I'd be -1 on requiring a JRE bump for 3.x on tika-core or any of the
> parsers, but luckily you're not actually suggesting that :)
>
> Given that we want to support our users who aren't ready to move to 4.x
> yet, and our upstream dependencies have forced this change on us, I'm +1
> for a targetted change on just the 3.x modules that need it (the two
> you're proposing!)
>
> Nick
>
Re: Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Nicholas DiPiazza <ni...@gmail.com>.
I see no better way
+1
On Mon, Oct 19, 2026, 2:57 PM Nick Burch <ni...@apache.org> wrote:
> On Mon, 19 Oct 2026, Tim Allison wrote:
> > I think the only safe way forward is to require jre 17 in tika 3.x's
> > tika-server and tika-server-standard. This would be on the next minor
> > release, say 3.4.0.
>
> I would prefer not to bump the JRE version without a major release, but I
> can't see any easy way to avoid that since we've already moved new
> development onto 4.x with a pile of other changes
>
> I'd be -1 on requiring a JRE bump for 3.x on tika-core or any of the
> parsers, but luckily you're not actually suggesting that :)
>
> Given that we want to support our users who aren't ready to move to 4.x
> yet, and our upstream dependencies have forced this change on us, I'm +1
> for a targetted change on just the 3.x modules that need it (the two
> you're proposing!)
>
> Nick
>
Re: Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Nick Burch <ni...@apache.org>.
On Mon, 19 Oct 2026, Tim Allison wrote:
> I think the only safe way forward is to require jre 17 in tika 3.x's
> tika-server and tika-server-standard. This would be on the next minor
> release, say 3.4.0.
I would prefer not to bump the JRE version without a major release, but I
can't see any easy way to avoid that since we've already moved new
development onto 4.x with a pile of other changes
I'd be -1 on requiring a JRE bump for 3.x on tika-core or any of the
parsers, but luckily you're not actually suggesting that :)
Given that we want to support our users who aren't ready to move to 4.x
yet, and our upstream dependencies have forced this change on us, I'm +1
for a targetted change on just the 3.x modules that need it (the two
you're proposing!)
Nick
Re: Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Nick Burch <ni...@apache.org>.
On Mon, 19 Oct 2026, Tim Allison wrote:
> I think the only safe way forward is to require jre 17 in tika 3.x's
> tika-server and tika-server-standard. This would be on the next minor
> release, say 3.4.0.
I would prefer not to bump the JRE version without a major release, but I
can't see any easy way to avoid that since we've already moved new
development onto 4.x with a pile of other changes
I'd be -1 on requiring a JRE bump for 3.x on tika-core or any of the
parsers, but luckily you're not actually suggesting that :)
Given that we want to support our users who aren't ready to move to 4.x
yet, and our upstream dependencies have forced this change on us, I'm +1
for a targetted change on just the 3.x modules that need it (the two
you're proposing!)
Nick
Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Tim Allison <ta...@apache.org>.
All,
I think the only safe way forward is to require jre 17 in tika 3.x's
tika-server and tika-server-standard. This would be on the next minor
release, say 3.4.0.
WDYT?
See: https://issues.apache.org/jira/browse/TIKA-4979 and
https://github.com/apache/tika/pull/3368
Best,
Tim
On Fri, Oct 9, 2026 at 3:03 PM Tim Allison <ta...@apache.org> wrote:
>
> All,
>
> We never made an EOL for 3.x announcement. We're not held to any decisions.
>
> I was reminded today that CXF has stopped releasing 4.0.x. The last
> release was 4.0.11 in February. Branch_3x is on 4.0.11, so
> tika-server's CXF in Tika 3.x is effectively unsupported.
>
> ~Ten CXF CVEs were announced today.
>
> Jetty is in the same spot. Jetty 11 went end-of-life on 1 January
> 2025, and 11.0.26, which branch_3x uses, is the last 11.x artifact.
> Jetty 12 requires Java 17.
>
> CXF 3.6.x is still maintained on Java 11, but it's javax.*, and
> branch_3x is already on jakarta.*, so that's a namespace downgrade
> across 3.x, not a version bump.
>
> The only real fix is to move branch_3x to Java 17 and pick up CXF
> 4.1.x and Jetty 12.
>
> Ideas? Shorten the EOL for 3x or move to 17 in 3.x soonish?
>
> Best,
>
> Tim
>
> On Mon, Aug 24, 2026 at 12:11 PM Eric Pugh
> <ep...@opensourceconnections.com> wrote:
> >
> > 18 works. Honestly, any number *can* be changed in the future. You wouldn’t want to do it capriocsly, but we aren’t bound to anything beyond public perception.
> >
> > In a lot of ways, just communicating clearly the expectations is the key thing.
> >
> >
> > > On Aug 24, 2026, at 10:57 AM, Tilman Hausherr <TH...@t-online.de> wrote:
> > >
> > > I'd concur with the highest number that other people who have a higher involvement are willing to accept.
> > > Tilman
> > >
> > > Am 24.08.2026 um 16:49 schrieb Tim Allison:
> > >> Makes sense.
> > >>
> > >> Tilman and Eric, is 18 months acceptable?
> > >>
> > >> On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
> > >>> Am 24.08.2026 um 15:58 schrieb Tim Allison:
> > >>>> What do others think?
> > >>>
> > >>> I'm always in favor of long maintenance times because of users bound to
> > >>> "old" jdk's.
> > >>>
> > >>> Tilman
> > >>>
> > >
> >
> > 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.
Requiring jre 17 for tika 3.x's tika-server and tika-server-standard?
Posted by Tim Allison <ta...@apache.org>.
All,
I think the only safe way forward is to require jre 17 in tika 3.x's
tika-server and tika-server-standard. This would be on the next minor
release, say 3.4.0.
WDYT?
See: https://issues.apache.org/jira/browse/TIKA-4979 and
https://github.com/apache/tika/pull/3368
Best,
Tim
On Fri, Oct 9, 2026 at 3:03 PM Tim Allison <ta...@apache.org> wrote:
>
> All,
>
> We never made an EOL for 3.x announcement. We're not held to any decisions.
>
> I was reminded today that CXF has stopped releasing 4.0.x. The last
> release was 4.0.11 in February. Branch_3x is on 4.0.11, so
> tika-server's CXF in Tika 3.x is effectively unsupported.
>
> ~Ten CXF CVEs were announced today.
>
> Jetty is in the same spot. Jetty 11 went end-of-life on 1 January
> 2025, and 11.0.26, which branch_3x uses, is the last 11.x artifact.
> Jetty 12 requires Java 17.
>
> CXF 3.6.x is still maintained on Java 11, but it's javax.*, and
> branch_3x is already on jakarta.*, so that's a namespace downgrade
> across 3.x, not a version bump.
>
> The only real fix is to move branch_3x to Java 17 and pick up CXF
> 4.1.x and Jetty 12.
>
> Ideas? Shorten the EOL for 3x or move to 17 in 3.x soonish?
>
> Best,
>
> Tim
>
> On Mon, Aug 24, 2026 at 12:11 PM Eric Pugh
> <ep...@opensourceconnections.com> wrote:
> >
> > 18 works. Honestly, any number *can* be changed in the future. You wouldn’t want to do it capriocsly, but we aren’t bound to anything beyond public perception.
> >
> > In a lot of ways, just communicating clearly the expectations is the key thing.
> >
> >
> > > On Aug 24, 2026, at 10:57 AM, Tilman Hausherr <TH...@t-online.de> wrote:
> > >
> > > I'd concur with the highest number that other people who have a higher involvement are willing to accept.
> > > Tilman
> > >
> > > Am 24.08.2026 um 16:49 schrieb Tim Allison:
> > >> Makes sense.
> > >>
> > >> Tilman and Eric, is 18 months acceptable?
> > >>
> > >> On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
> > >>> Am 24.08.2026 um 15:58 schrieb Tim Allison:
> > >>>> What do others think?
> > >>>
> > >>> I'm always in favor of long maintenance times because of users bound to
> > >>> "old" jdk's.
> > >>>
> > >>> Tilman
> > >>>
> > >
> >
> > 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.
Re: EOL for 3.x?
Posted by Tim Allison <ta...@apache.org>.
All,
We never made an EOL for 3.x announcement. We're not held to any decisions.
I was reminded today that CXF has stopped releasing 4.0.x. The last
release was 4.0.11 in February. Branch_3x is on 4.0.11, so
tika-server's CXF in Tika 3.x is effectively unsupported.
~Ten CXF CVEs were announced today.
Jetty is in the same spot. Jetty 11 went end-of-life on 1 January
2025, and 11.0.26, which branch_3x uses, is the last 11.x artifact.
Jetty 12 requires Java 17.
CXF 3.6.x is still maintained on Java 11, but it's javax.*, and
branch_3x is already on jakarta.*, so that's a namespace downgrade
across 3.x, not a version bump.
The only real fix is to move branch_3x to Java 17 and pick up CXF
4.1.x and Jetty 12.
Ideas? Shorten the EOL for 3x or move to 17 in 3.x soonish?
Best,
Tim
On Mon, Aug 24, 2026 at 12:11 PM Eric Pugh
<ep...@opensourceconnections.com> wrote:
>
> 18 works. Honestly, any number *can* be changed in the future. You wouldn’t want to do it capriocsly, but we aren’t bound to anything beyond public perception.
>
> In a lot of ways, just communicating clearly the expectations is the key thing.
>
>
> > On Aug 24, 2026, at 10:57 AM, Tilman Hausherr <TH...@t-online.de> wrote:
> >
> > I'd concur with the highest number that other people who have a higher involvement are willing to accept.
> > Tilman
> >
> > Am 24.08.2026 um 16:49 schrieb Tim Allison:
> >> Makes sense.
> >>
> >> Tilman and Eric, is 18 months acceptable?
> >>
> >> On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
> >>> Am 24.08.2026 um 15:58 schrieb Tim Allison:
> >>>> What do others think?
> >>>
> >>> I'm always in favor of long maintenance times because of users bound to
> >>> "old" jdk's.
> >>>
> >>> Tilman
> >>>
> >
>
> 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.
Re: EOL for 3.x?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
18 works. Honestly, any number *can* be changed in the future. You wouldn’t want to do it capriocsly, but we aren’t bound to anything beyond public perception.
In a lot of ways, just communicating clearly the expectations is the key thing.
> On Aug 24, 2026, at 10:57 AM, Tilman Hausherr <TH...@t-online.de> wrote:
>
> I'd concur with the highest number that other people who have a higher involvement are willing to accept.
> Tilman
>
> Am 24.08.2026 um 16:49 schrieb Tim Allison:
>> Makes sense.
>>
>> Tilman and Eric, is 18 months acceptable?
>>
>> On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
>>> Am 24.08.2026 um 15:58 schrieb Tim Allison:
>>>> What do others think?
>>>
>>> I'm always in favor of long maintenance times because of users bound to
>>> "old" jdk's.
>>>
>>> Tilman
>>>
>
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.
Re: EOL for 3.x?
Posted by Tilman Hausherr <TH...@t-online.de>.
I'd concur with the highest number that other people who have a higher
involvement are willing to accept.
Tilman
Am 24.08.2026 um 16:49 schrieb Tim Allison:
> Makes sense.
>
> Tilman and Eric, is 18 months acceptable?
>
> On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
>> Am 24.08.2026 um 15:58 schrieb Tim Allison:
>>> What do others think?
>>
>> I'm always in favor of long maintenance times because of users bound to
>> "old" jdk's.
>>
>> Tilman
>>
Re: EOL for 3.x?
Posted by Tim Allison <ta...@apache.org>.
Makes sense.
Tilman and Eric, is 18 months acceptable?
On Mon, Aug 24, 2026 at 10:17 AM Tilman Hausherr <TH...@t-online.de> wrote:
>
> Am 24.08.2026 um 15:58 schrieb Tim Allison:
> > What do others think?
>
>
> I'm always in favor of long maintenance times because of users bound to
> "old" jdk's.
>
> Tilman
>
Re: EOL for 3.x?
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 24.08.2026 um 15:58 schrieb Tim Allison:
> What do others think?
I'm always in favor of long maintenance times because of users bound to
"old" jdk's.
Tilman
Re: EOL for 3.x?
Posted by Nicholas DiPiazza <ni...@gmail.com>.
18 months is a nice number
On Mon, Aug 24, 2026, 8:58 AM Tim Allison <ta...@apache.org> wrote:
> Thank you, Eric.
>
> Tika is used both as a library and a service. I'm not sure there's a
> huge difference between breaking an API vs. breaking configuration and
> an endpoint's behavior. Moving to 4.x will take some effort, I
> acknowledge.
>
> I'm worried about the futility of claiming 5 years when, by then, a
> bunch of our dependencies will have moved to > Java 11, and we won't
> be getting _their_ security fixes in our 3.x branch.
>
> How about we propose 18 months for maintenance and security?
>
> What do others think?
>
> On Wed, Aug 19, 2026 at 8:03 AM Eric Pugh
> <ep...@opensourceconnections.com> wrote:
> >
> > I know we want to all EOL the last version, but in this time of CVEs
> etc, having short EOL is tough.
> >
> > What would prevent someone using 3 from moving to 4? The reason I ask is
> that if you are moving faster to EOL than your downstream customers are
> updating and releasing, then you can put the in a tough spot. Obviously,
> this is more prevalent for libraries than server code.
> >
> > A case in point.. Solr 9 runs on Java 11. Solr 10 runs on Java 17 and
> later (and maybe even newer Java)…. Solr 9 has a large installed base.
> Solr leans on OpenNLP as a library, and in Solr 9 it uses OpenNLP 1, which
> also shares java 11. OpenNLP moves in 2.0 to using newer versions of Java,
> which means we can’t upgrade Solr 9 to using OpenNLP 2…. Yet folks will
> be using Solr 9 for years more before they move to Solr 10 (or even jump to
> 11 or 12!). So now we are faced with, do we accept the various CVE’s
> etc that impact OpenNLP 1, or do we rip it out….. Which is a breaking
> change for Solr 9 users and leaves them with a less functional Solr.
> >
> > In the case of Tika, we actually kind of had the same thing.. Yes,
> Solr has been on Tika 1 for a long time, and so the pile of CVE’s etc meant
> that in Solr 9.10 we actually made the breaking change of making Tika
> accessible from Solr not as a library but as a separate server app,
> basically because the effort to upgrade from Tika 1 to Tika 3 as an
> embedded app was too much, especially in a minor version release. It
> was…. Not ideal…. And a lot of work…. To say the least!
> >
> >
> > Maybe my tl;dr is to decide “Is Tika library that gets embedded or a
> server app that gets deployed”….. If it’s a server app, then I still
> think you should think about not EOL’ing for a an extended time, say 18 to
> 24 months. And if it’s a library, then 5 years? These time frames are
> based on the idea that lots of folks build an app, and then ship it, and it
> just does what it does in production for a long time. And that forced
> upgrades are not what folks want.
> >
> >
> >
> > > On Aug 19, 2026, at 7:16 AM, Tim Allison <ta...@apache.org> wrote:
> > >
> > > All,
> > > What do we want to set the EOL for 3.x to be? The migration to 4.x
> > > is quite a step, and I want to give people time.
> > > At one point, I think we were thinking 6 months after the release of
> 4.0.0.
> > > A year feels somewhat too long to me... 9 months (May 2027)?
> > >
> > > wdyt?
> > >
> > > Cheers,
> > >
> > > Tim
> > >
> >
> > 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.
>
Re: EOL for 3.x?
Posted by Tim Allison <ta...@apache.org>.
Thank you, Eric.
Tika is used both as a library and a service. I'm not sure there's a
huge difference between breaking an API vs. breaking configuration and
an endpoint's behavior. Moving to 4.x will take some effort, I
acknowledge.
I'm worried about the futility of claiming 5 years when, by then, a
bunch of our dependencies will have moved to > Java 11, and we won't
be getting _their_ security fixes in our 3.x branch.
How about we propose 18 months for maintenance and security?
What do others think?
On Wed, Aug 19, 2026 at 8:03 AM Eric Pugh
<ep...@opensourceconnections.com> wrote:
>
> I know we want to all EOL the last version, but in this time of CVEs etc, having short EOL is tough.
>
> What would prevent someone using 3 from moving to 4? The reason I ask is that if you are moving faster to EOL than your downstream customers are updating and releasing, then you can put the in a tough spot. Obviously, this is more prevalent for libraries than server code.
>
> A case in point.. Solr 9 runs on Java 11. Solr 10 runs on Java 17 and later (and maybe even newer Java)…. Solr 9 has a large installed base. Solr leans on OpenNLP as a library, and in Solr 9 it uses OpenNLP 1, which also shares java 11. OpenNLP moves in 2.0 to using newer versions of Java, which means we can’t upgrade Solr 9 to using OpenNLP 2…. Yet folks will be using Solr 9 for years more before they move to Solr 10 (or even jump to 11 or 12!). So now we are faced with, do we accept the various CVE’s etc that impact OpenNLP 1, or do we rip it out….. Which is a breaking change for Solr 9 users and leaves them with a less functional Solr.
>
> In the case of Tika, we actually kind of had the same thing.. Yes, Solr has been on Tika 1 for a long time, and so the pile of CVE’s etc meant that in Solr 9.10 we actually made the breaking change of making Tika accessible from Solr not as a library but as a separate server app, basically because the effort to upgrade from Tika 1 to Tika 3 as an embedded app was too much, especially in a minor version release. It was…. Not ideal…. And a lot of work…. To say the least!
>
>
> Maybe my tl;dr is to decide “Is Tika library that gets embedded or a server app that gets deployed”….. If it’s a server app, then I still think you should think about not EOL’ing for a an extended time, say 18 to 24 months. And if it’s a library, then 5 years? These time frames are based on the idea that lots of folks build an app, and then ship it, and it just does what it does in production for a long time. And that forced upgrades are not what folks want.
>
>
>
> > On Aug 19, 2026, at 7:16 AM, Tim Allison <ta...@apache.org> wrote:
> >
> > All,
> > What do we want to set the EOL for 3.x to be? The migration to 4.x
> > is quite a step, and I want to give people time.
> > At one point, I think we were thinking 6 months after the release of 4.0.0.
> > A year feels somewhat too long to me... 9 months (May 2027)?
> >
> > wdyt?
> >
> > Cheers,
> >
> > Tim
> >
>
> 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.
Re: EOL for 3.x?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I know we want to all EOL the last version, but in this time of CVEs etc, having short EOL is tough.
What would prevent someone using 3 from moving to 4? The reason I ask is that if you are moving faster to EOL than your downstream customers are updating and releasing, then you can put the in a tough spot. Obviously, this is more prevalent for libraries than server code.
A case in point.. Solr 9 runs on Java 11. Solr 10 runs on Java 17 and later (and maybe even newer Java)…. Solr 9 has a large installed base. Solr leans on OpenNLP as a library, and in Solr 9 it uses OpenNLP 1, which also shares java 11. OpenNLP moves in 2.0 to using newer versions of Java, which means we can’t upgrade Solr 9 to using OpenNLP 2…. Yet folks will be using Solr 9 for years more before they move to Solr 10 (or even jump to 11 or 12!). So now we are faced with, do we accept the various CVE’s etc that impact OpenNLP 1, or do we rip it out….. Which is a breaking change for Solr 9 users and leaves them with a less functional Solr.
In the case of Tika, we actually kind of had the same thing.. Yes, Solr has been on Tika 1 for a long time, and so the pile of CVE’s etc meant that in Solr 9.10 we actually made the breaking change of making Tika accessible from Solr not as a library but as a separate server app, basically because the effort to upgrade from Tika 1 to Tika 3 as an embedded app was too much, especially in a minor version release. It was…. Not ideal…. And a lot of work…. To say the least!
Maybe my tl;dr is to decide “Is Tika library that gets embedded or a server app that gets deployed”….. If it’s a server app, then I still think you should think about not EOL’ing for a an extended time, say 18 to 24 months. And if it’s a library, then 5 years? These time frames are based on the idea that lots of folks build an app, and then ship it, and it just does what it does in production for a long time. And that forced upgrades are not what folks want.
> On Aug 19, 2026, at 7:16 AM, Tim Allison <ta...@apache.org> wrote:
>
> All,
> What do we want to set the EOL for 3.x to be? The migration to 4.x
> is quite a step, and I want to give people time.
> At one point, I think we were thinking 6 months after the release of 4.0.0.
> A year feels somewhat too long to me... 9 months (May 2027)?
>
> wdyt?
>
> Cheers,
>
> Tim
>
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.
Re: EOL for 3.x?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I know we want to all EOL the last version, but in this time of CVEs etc, having short EOL is tough.
What would prevent someone using 3 from moving to 4? The reason I ask is that if you are moving faster to EOL than your downstream customers are updating and releasing, then you can put the in a tough spot. Obviously, this is more prevalent for libraries than server code.
A case in point.. Solr 9 runs on Java 11. Solr 10 runs on Java 17 and later (and maybe even newer Java)…. Solr 9 has a large installed base. Solr leans on OpenNLP as a library, and in Solr 9 it uses OpenNLP 1, which also shares java 11. OpenNLP moves in 2.0 to using newer versions of Java, which means we can’t upgrade Solr 9 to using OpenNLP 2…. Yet folks will be using Solr 9 for years more before they move to Solr 10 (or even jump to 11 or 12!). So now we are faced with, do we accept the various CVE’s etc that impact OpenNLP 1, or do we rip it out….. Which is a breaking change for Solr 9 users and leaves them with a less functional Solr.
In the case of Tika, we actually kind of had the same thing.. Yes, Solr has been on Tika 1 for a long time, and so the pile of CVE’s etc meant that in Solr 9.10 we actually made the breaking change of making Tika accessible from Solr not as a library but as a separate server app, basically because the effort to upgrade from Tika 1 to Tika 3 as an embedded app was too much, especially in a minor version release. It was…. Not ideal…. And a lot of work…. To say the least!
Maybe my tl;dr is to decide “Is Tika library that gets embedded or a server app that gets deployed”….. If it’s a server app, then I still think you should think about not EOL’ing for a an extended time, say 18 to 24 months. And if it’s a library, then 5 years? These time frames are based on the idea that lots of folks build an app, and then ship it, and it just does what it does in production for a long time. And that forced upgrades are not what folks want.
> On Aug 19, 2026, at 7:16 AM, Tim Allison <ta...@apache.org> wrote:
>
> All,
> What do we want to set the EOL for 3.x to be? The migration to 4.x
> is quite a step, and I want to give people time.
> At one point, I think we were thinking 6 months after the release of 4.0.0.
> A year feels somewhat too long to me... 9 months (May 2027)?
>
> wdyt?
>
> Cheers,
>
> Tim
>
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.