DXP Free Tier License Compatibility Across Quarterly Releases

Understanding Quarterly Version Compatibility in DXP Free Tier Licenses

David H Nebinger
David H Nebinger
2 من الدقائق قراءة

When I started working through the new DXP Free Tier onboarding flow for an upcoming blog post, I stumbled across something that initially looked wrong.

After generating my free activation key, I downloaded the activation key file named: activation-key-dxp-production-2026.q2-.xml 

At the time, 2026.Q2 had not even been released yet.

Naturally, that raised some questions.

When I opened the XML, I found this:

<?xml version="1.0"?>

<license>
  <account-name>Liferay Free Activation Key</account-name>
  <owner>...</owner>
  <description>Liferay Free Activation Key</description>
  <product-name>DXP Production</product-name>
  <product-version>2026.Q2</product-version>
  <license-name>DXP Production</license-name>
  <license-type>free</license-type>
  <license-version>6</license-version>
  <start-date>Wednesday, May 13, 2026 
    7:15:40 PM GMT</start-date>
  <expiration-date>Thursday, May 13, 2027 
    7:15:40 PM GMT</expiration-date>
  <max-cluster-nodes>3</max-cluster-nodes>
  <domains>
    <domain>...</domain>
    <domain>localhost</domain>
  </domains>
  <instance-size>Sizing 4</instance-size>
  <key>...</key>
</license>

And there it was:

<product-version>2026.Q2</product-version> 

At first glance, it looked like the license generator had somehow produced a license for a future release.

What Was Actually Happening

I reached out to the licensing team and got clarification.

The explanation was simple. I generated the license while the team was actively preparing the 2026.Q2 release, so the generator had already switched internally to the upcoming quarterly version.

So the filename and <product-version> value reflected the current release pipeline state, not necessarily a hard compatibility restriction.

Mystery solved.

But the more important discovery came next.

The Product Version Is Not a Strict Compatibility Boundary

This is the part that matters to DXP Free Tier users.

Even though the license says: 

<product-version>2026.Q2</product-version> 

the license still works perfectly fine with 2026.Q1.6 and the upcoming 2026.Q1.7.

That means the quarterly version embedded in the license is not a strict “this only works on exactly this release” constraint.

Instead, compatibility spans quarterly releases within the supported generation.

Why This Matters

Without knowing this behavior, it would be easy for users to assume they downloaded the wrong license or needed a separate activation key for older quarterly releases.

That is not the case.

If later in the year you generate a license containing:

<product-version>2026.Q4</product-version> 

but your environment is still running 2026.Q1, you should still be fine.

You do not need to open a support ticket asking how to generate a 2026.Q1 activation key specifically.

Why This Approach Makes Sense

Operationally, this is actually a reasonable licensing model.

If quarterly compatibility were enforced rigidly, every patch train would require separate license generation and upgrades between quarterly releases would become unnecessarily painful.

Instead, the licensing model appears intentionally flexible enough to accommodate staggered upgrades and overlapping release cycles without forcing users to constantly regenerate activation keys.

That flexibility is especially important for developers evaluating DXP locally or in small environments.

Practical Takeaway

If you are using the DXP Free Tier, do not panic if the license version looks newer than your runtime version.

The <product-version> value is not necessarily an exact-match requirement, and newer quarterly licenses appear compatible with earlier quarterly releases within the same yearly stream.

Final Thoughts

This was one of those small details that could easily confuse new users during onboarding.

The filename and XML strongly imply strict version binding, but the actual behavior is intentionally more flexible.

From an engineering perspective, that is probably the correct tradeoff. It reduces operational friction while still allowing licensing metadata to track the active release train internally.

And if you are building tutorials, demos, PoCs, or evaluation environments using the DXP Free Tier, it is a useful detail to understand before spending time chasing the wrong problem.

تعليقات الصفحة

Related Assets...

لا توجد نتائج

More Blog Entries...

David H Nebinger
مايو ١٤, ٢٠٢٦
David H Nebinger
مايو ١٣, ٢٠٢٦