Last checked and updated on 30 May 2026
How Does PrimeFaces Handle Version Support -- STS vs LTS?
PrimeFaces operates on a two-track support model managed by PrimeTek Informatics. The current major release is always on STS (Short-Term Support) -- fully open source under the MIT license, free to use, with bug fixes and patches published to Maven Central until the next major version ships. Once a new major version is released, the previous one transitions to LTS (Long-Term Support) -- a commercial service where PrimeTek continues to backport security fixes and defect patches for paying subscribers.
There is no published EOL date for any PrimeFaces version. Instead, what changes is the support tier: free maintenance stops when the next major release arrives, and commercial LTS takes over for teams that cannot or will not upgrade immediately.
| Track | Who Maintains It | Cost | How Long | Artifact Suffix |
|---|---|---|---|---|
| STS -- current major | PrimeTek + open source community | Free (MIT) | Until next major release | No suffix (e.g. 15.0.4) |
| LTS -- previous major(s) | PrimeTek (closed-source fixes) | Paid license per organization | Annual Basic or unlimited Extended | -LTS suffix (e.g. 14.0.13-LTS) |
| Legacy -- older majors (pre-7) | Community only | Free (MIT) | No active maintenance | No suffix, no updates |
The community GitHub repository only accepts bug reports reproducible against the current STS major version. Backporting fixes to LTS branches is exclusively handled by PrimeTek -- community contributors cannot port fixes there. For authoritative details, see the official PrimeFaces LTS page.
What Breaks When You Stay on an Older PrimeFaces Version?
The most tangible risk with outdated PrimeFaces versions is JSF implementation drift. PrimeFaces depends heavily on the behavior of your JSF implementation (Mojarra or MyFaces), and both implementations continue releasing patches that can subtly change rendering, AJAX lifecycle, or EL evaluation. An old PrimeFaces version tested against one Mojarra patch level may behave unexpectedly against a newer one -- and without active maintenance, those incompatibilities never get fixed.
Component rendering bugs are the second pressure point. PrimeFaces components rely on specific browser APIs and CSS behavior. Browsers ship updates continuously, and older PrimeFaces versions accumulate visual regressions -- broken dropdowns, misaligned overlays, or AJAX submission failures -- that only get resolved in newer releases or LTS patches.
Specific risks by area
| Risk Area | Description |
|---|---|
| JSF implementation mismatch | Mojarra and MyFaces patch releases can break PrimeFaces component behavior in ways only fixed upstream |
| Browser compatibility | Chrome, Firefox, and Safari regularly drop deprecated APIs that older PrimeFaces JavaScript depends on |
| Jakarta EE namespace | Versions below 12.0 do not support the jakarta.* namespace -- incompatible with Jakarta Faces 4.0+ containers |
| Security vulnerabilities | XSS issues in components like CommandButton and CSP-related bugs have been patched only in LTS and recent STS releases |
| Third-party dependency CVEs | Bundled libraries (e.g. org.json) carry their own CVEs that only get updated in maintained branches |
What Happens to Your PrimeFaces Version After Free Support Ends?
When PrimeTek ships a new major version, the previous major immediately transitions from STS to LTS. The MIT-licensed JAR you already have deployed does not stop working -- your application keeps running. What stops is free maintenance: no more patches are published to Maven Central for that version without an LTS subscription.
At that point you have three options: upgrade to the new STS major (free, but requires testing and potentially migration work), purchase an LTS license to keep receiving patches on your current version (paid, per organization), or freeze and accept that your version will accumulate unpatched bugs and browser regressions over time.
In practice, most teams find the freeze option untenable beyond 12-18 months because browser updates will eventually break component rendering. The JSF ecosystem moves slowly compared to React or Angular, but it does move -- and PrimeFaces component JavaScript is exposed to browser churn just like any other UI library.
| After New Major Ships | Free (MIT) Users | LTS Subscribers |
|---|---|---|
| Bug fixes | None for old version | Continued via PrimeTek |
| Security patches | None for old version | Backported to LTS branch |
| Existing JAR | Still works, MIT license intact | Still works, MIT license intact |
| Maven Central updates | No new patch releases | New -LTS patch releases |
How Do You Check Your PrimeFaces Version?
There are several ways to confirm the exact PrimeFaces version your application is running, depending on whether you are checking at build time or runtime.
Check via Maven
mvn dependency:tree | grep primefacesThis shows both the version and the classifier. A jakarta classifier means you are on the Jakarta EE namespace build:
[INFO] +- org.primefaces:primefaces:jar:15.0.4:compile
[INFO] +- org.primefaces:primefaces:jar:jakarta:14.0.13-LTS:compileCheck via Gradle
./gradlew dependencies --configuration compileClasspath | grep primefacesCheck at runtime via the PrimeFaces API
From within any managed bean or servlet filter, you can read the version programmatically:
String version = org.primefaces.util.Constants.VERSION;
// Returns e.g. "15.0.4" or "14.0.13-LTS"Identify javax vs jakarta namespace
If you are unsure which namespace build you are on, check your pom.xml dependency declaration:
<!-- javax namespace (JSF 2.x) -- no classifier -->
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>15.0.4</version>
</dependency>
<!-- jakarta namespace (Faces 4.0+) -- jakarta classifier -->
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>15.0.4</version>
<classifier>jakarta</classifier>
</dependency>The presence or absence of the <classifier>jakarta</classifier> tag is the definitive indicator of which namespace build you are running.
FAQ
Q1: Is PrimeFaces LTS required, or can I stay on the free STS version indefinitely?
LTS is optional. You can continue using any STS version under its MIT license indefinitely -- the license is not revoked when a new major ships. What you lose is free maintenance: no new patch releases will appear on Maven Central for that version. If your application is stable and browser regressions are not a concern, staying on a frozen STS version is a valid choice for low-change internal applications. For anything customer-facing, unpatched browser compatibility issues tend to become a problem within 12-18 months.
Q2: What is the difference between PrimeFaces LTS and PrimeFaces PRO?
LTS is a license that grants your organization access to continued patch releases for a previous major version -- it is about getting maintenance updates, not about getting answers from PrimeTek engineers. PRO is a separate engagement model where PrimeTek engineers respond to your specific issues within one business day via a private JIRA instance. PRO subscribers also receive LTS access as part of the package. If you just need security patches, LTS is sufficient. If you need guaranteed engineering response time, PRO is the relevant tier.
Q3: Do I need the jakarta classifier when migrating from Tomcat 9 to Tomcat 10?
Yes. Tomcat 10 implements Jakarta Faces 3.0+ and uses the jakarta.* namespace. If your PrimeFaces dependency does not include the jakarta classifier, the JAR will be built against the javax.* namespace and will fail to load in Tomcat 10 with classloading errors. You must add the classifier and update all your JSF/Faces imports from javax.faces to jakarta.faces at the same time.
Q4: Can I mix PrimeFaces versions in a multi-module Maven project?
No. PrimeFaces should be declared once in a parent BOM or dependency management section and used at the same version across all modules. Mixing versions in the same WAR will result in conflicting tag library descriptors and unpredictable component rendering -- the Faces runtime loads one primefaces.taglib.xml and ignores the rest, so whichever version wins the classloader race defines the component behavior for the whole application.
Q5: Does PrimeFaces work on plain Servlet containers like Tomcat without a full Jakarta EE server?
Yes, with a caveat. PrimeFaces requires a JSF/Jakarta Faces implementation to be present -- it does not bundle one. On plain Tomcat, you need to add either Mojarra or Apache MyFaces as a dependency alongside PrimeFaces. Full Jakarta EE servers like WildFly or GlassFish ship with a Faces implementation built in. The PrimeFaces JAR itself is the same regardless of container -- only the Faces implementation and the namespace classifier differ between deployment targets. See the official repository README for setup instructions by container type.