Akeneo Community Edition v2026.3: the release that was not supposed to happen
Akeneo signalled the end of Community Edition, then shipped v2026.3 in 2026: PHP 8.3, MySQL 8.0.34, Elasticsearch 8.17. What the release actually contains, what it left unfixed, and what it means if you run 7.0.x.
Since 2023 everyone in the Akeneo ecosystem has repeated the same sentence: Community Edition is finished. Development frozen, the roadmap moved to the cloud editions, support running out in September 2026. Some companies planned a migration, some postponed the decision, and some started looking at Pimcore or Ergonode instead.
Then, with no announcement, a new tag appeared in pim-community-dev: v2026.3. A new versioning scheme, a new default branch, PHP 8.3 instead of 8.1. We went through what is actually in that release, because the gap between “Akeneo brought Community back” and what sits in the repository is, in this case, wide.
Update, 3 September 2026. The day after this piece went out, on 28 August, Akeneo tagged v2026.4, and that release contains the MySQL 8.4 LTS commit whose absence we describe below as the main problem. The analysis of v2026.3 itself stands unchanged, because it is about that release and is still accurate, but two of its conclusions have moved and are corrected in the text: MySQL 8.4 is now in a release, and 2026 holds three tagged Community releases rather than one. The recommendation does not change, because it never rested on release cadence.
What actually happened
The timeline is simpler than the commentary around it, and worth knowing, because the version circulating on the market is garbled.
| Date | What happened |
|---|---|
| 27 January 2026 | Commit chore: initialize community edition tech refresh (new main). A main branch appears beside the old master, and Enterprise tests are dropped from the CI pipeline |
| 10 February 2026 | Release tagged 2026-2, still without the v prefix, carrying the full infrastructure refresh notes |
| 30 March 2026 | Four commits tidying up the numbering, and the tag v2026.3 |
| 10 June 2026 | Commit Community Edition Tech Refresh - MySQL 8.4 LTS. Outside any tag, as it turned out, for 79 days |
| 17 June 2026 | Tag v7.0.85 on the old 7.0 branch |
| 27–28 August 2026 | The silence ends: three commits on main and the tag v2026.4, which carries that June MySQL 8.4 work |
The first surprise on comparing the two tags: v2026.3 is not the successor to v7.0.85. GitHub describes the branches as diverged, 35 commits ahead and 3 behind. v2026.3 is two and a half months older. These are two parallel lines rather than one timeline, so a company sitting on 7.0.85 has not fallen one release behind, it is standing on a different branch.
The second, and here the piece dated itself: at the time of writing the last commit was 17 June, ten weeks earlier. The silence broke the next day. Three commits and the tag v2026.4 landed on 27 and 28 August, which means ten quiet weeks in this repository are not yet evidence that the project has been dropped. Worth remembering at the next such gap.
What is in v2026.3
This is a technical release, not a functional one. It contains no new PIM capability at all: no new attribute type, no change to rules, imports or the API. The whole payload is a lift of the runtime layer.
| Component | 7.0.85 | v2026.3 |
|---|---|---|
| PHP | 8.1 | 8.3 |
| MySQL | 8.0.30 | 8.0.34 |
| Elasticsearch (server) | 8.4.2 | 8.17.0 |
lcobucci/jwt | ^4.2 | ^5.2 |
| Node image | 18 | 18 |
| Symfony | 5.4 | 5.4 |
One of those changes was urgent, and it explains the whole exercise. PHP 8.1 lost security support on 31 December 2025. An Akeneo Community installation on 7.0.x has been running since January 2026 on an interpreter that receives no patches whatsoever. PHP 8.3 has security support until 31 December 2027, so the refresh buys two years.
The rest sits in the same category: dropping the deprecated mysql_native_password authentication, fixing DateTime::getLastErrors() compatibility, upgrading phpspec/prophecy rather than silencing its warnings. Solid, unglamorous maintenance work.
What v2026.3 did not fix
This is the part missing from the release notes, and it decides how long such an installation will actually hold.
MySQL 8.0 reached end of life on 30 April 2026. v2026.3 was tagged on 30 March, one month before that date, with MySQL 8.0.34 in docker-compose.yml. The move to MySQL 8.4 LTS (supported until 2032) was written in June, complete with a new MySQL84Platform class and a change to PimRequirements.php, but it sat outside any release for 79 days.
v2026.4, on 28 August, closed it, after this piece was published: docker-compose.yml there carries mysql:8.4.9, and PimRequirements.php now requires at least 8.4.0 and accepts anything below 9.0. Install from the newest tag and you get a supported database. Stay on v2026.3 and you do not, which is the practical takeaway from this section: when you upgrade, target v2026.4, not v2026.3.
The Node image in the repository is still akeneo/node:18. Node 18 went out of support on 30 April 2025, more than a year before this release. It affects the frontend build layer rather than the production runtime, but it is the same class of problem the refresh was meant to close.
Symfony stayed on 5.4. That is an LTS with security patches until February 2029, so it is not a hole, but bug support ended in November 2024 and the current Symfony line is 8.x. The framework underneath Akeneo Community is four major versions behind the market and the refresh did not touch it. The Elasticsearch PHP client is also pinned at 7.11.0 while the server moved to 8.17.
None of those three changed in v2026.4. That release holds four commits: MySQL 8.4, a backport of 7.0 branch fixes, strict_variables in the test environment, and one fix for a 500 error on the group creation page.
The sentence in the README to read before you upgrade
Along with the new numbering, Akeneo added a versioning policy to the README, and it is unusually blunt:
This project uses Calendar Versioning (vYYYY.Minor). Important: We do not follow Semantic Versioning (SemVer). We do not guarantee backwards compatibility between any two versions. Breaking changes may be introduced in any release.
In other words: no guarantee of backwards compatibility between any two releases whatsoever. A breaking change can land in any of them, including one that looks minor. The vendor’s own recommendation sits in the same place and reads “pin the exact version in composer.json”.
For a production installation that is a change of operating regime, not a detail. Under SemVer you can adopt the rule “patches we take immediately, majors we plan”. Under this policy every upgrade is a project: it needs a review of the changes, regression tests against your own integrations, and a deployment window. There is a second note in the README that is easy to miss: moving from 7.x to the new numbering requires all migrations from the 7.0 branch to be applied first.
So has the EOL been cancelled?
Not exactly, and the date most often quoted on the market applies to something other than what people attach it to.
30 September 2026 is the end-of-support date for Akeneo PIM 7.0 in the PaaS (Flexibility) and on-premise editions. Akeneo’s own support dates page states plainly that it covers only those editions and not Community Edition, and adds a separate line: “The Community Edition is continuously being supported by Akeneo”, pointing readers to the GitHub repository. Formally, then, Community never received an EOL date of its own, and the v2026.3 release is consistent with that stated position.
In practice the picture is this:
- 2026 holds three tagged CalVer releases:
2026-2(10 February),v2026.3(30 March) andv2026.4(28 August), - the most important technical fix waited 79 days for a release, but it is in a tag,
- the 7.0 branch received three releases in twelve months, one of which contained a single history-display fix,
- 374 issues are open in the repository,
- the vendor commits to no SLA and promises no compatibility.
This is not a dead project, and after v2026.4 it is no longer a project without a rhythm either: three releases a year is a cadence you can plan maintenance around. What remains is the thing that matters more than cadence, because the vendor does not promise that the next release will not break your installation. The difference matters, because it leads to a different decision than “migrate, because it is ending”.
What this means if you run Akeneo Community
Three situations, three different answers.
You are on 7.0.x and planned a migration “because of the EOL”. The pressure is lower than you assumed, but the PHP 8.1 problem is real and will not resolve itself. Upgrading to v2026.3 is cheaper than replacing the system and is worth weighing against a PIM swap. Upgrade to v2026.4 rather than v2026.3: the former brings MySQL 8.4, the latter leaves you on a database past its end of life.
You are considering Akeneo Community for a new implementation. Our recommendation here does not change: for a new project, we advise against it. Not because of an EOL, and no longer because of the release cadence, but because of the no-compatibility policy: that is what turns every upgrade into a project, and it has not changed by a word. If you need self-hosted, compare the cost of maintaining Community against the other PIM systems we implement, because Akeneo’s entire paid line (Growth, Advanced, Premium) is available today as SaaS only.
You have a working installation and would rather not touch it. This is the most common case and the most sensible one. An Akeneo Community doing its job across a catalogue of a few tens of thousands of SKUs is not a reason for a migration project. It is a reason to secure the security patches the vendor does not guarantee.
LTS for Akeneo Community: what we do at Macopedia
For our clients we are ready to provide an LTS service for Akeneo Community implementations, whatever cadence the vendor releases at. The scope is as follows:
- Security updates. We track vulnerabilities across the installation’s whole dependency tree, not just Akeneo itself: Symfony, Twig, dompdf, phpseclib, aws-sdk, guzzle and the other packages that are the realistic way into the application. Patches are backported to the version the client is on, without forcing a PIM version jump.
- Keeping the runtime layer on supported versions. PHP, MySQL and Elasticsearch, including work the vendor has not shipped in a tag. Today that means the Node 18 image, Symfony 5.4, and the Elasticsearch client pinned at 7.11.0 against an 8.17 server.
- A controlled 7.0.x to v2026.x path. With the 7.0 branch migrations applied in the right order and regression tests against the client’s integrations, because with no compatibility guarantee it is those tests, not a changelog, that prove an upgrade is safe.
- A pinned version and predictable windows. As the README recommends, but on our review schedule, so that upgrading is a decision rather than a reaction to an announcement.
We have been doing this since 2012 across e-commerce and PIM implementations, we are an Akeneo Registered Partner, and our team maintains and develops Akeneo installations for companies whose product catalogue is a business-critical system.
If you run Akeneo Community and want to know exactly where you stand, get in touch. We start with a review: which version, which dependencies, which of them carry known vulnerabilities today, and what that means for your schedule.
Summary
v2026.3 is good news and a weak basis for planning at the same time. Good, because Akeneo Community got PHP 8.3 and climbed out from under an unpatched interpreter, and because the market got a signal that the project is not abandoned. Weak, because it left the database past its end of life and the most important fix outside any tag for 79 days.
After v2026.4, half of that objection falls away: the database is supported, the release is the third of the year, and the repository is alive. The other half does not, and it is the deciding one. The README explicitly refuses backwards compatibility between any two releases, so a maintenance plan for a business-critical system still has nothing to stand on from the vendor’s side.
The 30 September 2026 date belongs to the PaaS and on-premise 7.0 editions, not to Community, and it is time to stop being frightened by it. The real question is a different one: who will supply your installation with security patches at a cadence you can put in a schedule.
A Product Information Management (PIM) expert and host of the "Akademia PIM" podcast, Karolina has extensive experience from both the client and implementation agency perspectives. This unique background allows her to effectively combine business needs with the technical aspects of PIM implementation. As a Project Manager and Business Analyst at Macopedia, she helps companies improve product information management and optimize operational processes through her publications.