Akeneo Community Edition v2026.3: wersja, której nie miało być
Akeneo zapowiadało koniec Community Edition, a w 2026 roku wydało v2026.3: PHP 8.3, MySQL 8.0.34, Elasticsearch 8.17. Sprawdzamy, co realnie doszło, czego wydanie nie naprawiło i co to znaczy dla firm na 7.0.x.
Od 2023 roku wszyscy w ekosystemie Akeneo powtarzali to samo zdanie: Community Edition się kończy. Rozwój wstrzymany, roadmapa przeniesiona do wersji chmurowych, wsparcie do września 2026. Część firm zdążyła zaplanować migrację, część odłożyła decyzję, a część zaczęła szukać alternatywy w Pimcore albo Ergonode.
A potem, bez zapowiedzi, w repozytorium pim-community-dev pojawił się nowy tag: v2026.3. Nowy schemat numeracji, nowa gałąź główna, PHP 8.3 zamiast 8.1. Sprawdziliśmy, co dokładnie w tym wydaniu jest, bo różnica między „Akeneo wróciło do Community” a tym, co faktycznie leży w repozytorium, jest w tym przypadku spora.
Aktualizacja z 3 września 2026. Nazajutrz po publikacji tego tekstu, 28 sierpnia, Akeneo otagowało v2026.4 i to wydanie zawiera commit z MySQL 8.4 LTS, którego brak opisywaliśmy niżej jako główny problem. Analizę samej v2026.3 zostawiamy bez zmian, bo dotyczy tego wydania i jest nadal prawdziwa, ale dwa wnioski się przez to zmieniły i są poprawione w tekście: MySQL 8.4 jest już w wydaniu, a rok 2026 ma trzy otagowane wydania Community, nie jedno. Rekomendacja się nie zmienia, bo nigdy nie stała na tempie wydań.
Co się właściwie stało
Chronologia jest prostsza, niż wygląda z zewnątrz, i warto ją znać, bo w komunikatach na rynku pojawia się przekręcona.
| Data | Co się wydarzyło |
|---|---|
| 27 stycznia 2026 | Commit chore: initialize community edition tech refresh (new main). Powstaje gałąź main obok starego master, a z pipeline’u CI wylatują testy Enterprise |
| 10 lutego 2026 | Wydanie oznaczone 2026-2, jeszcze bez przedrostka v, z pełnymi notatkami o odświeżeniu infrastruktury |
| 30 marca 2026 | Cztery commity porządkujące numerację i tag v2026.3 |
| 10 czerwca 2026 | Commit Community Edition Tech Refresh - MySQL 8.4 LTS. Poza jakimkolwiek tagiem, jak się okazało, przez 79 dni |
| 17 czerwca 2026 | Tag v7.0.85 na starej gałęzi 7.0 |
| 27–28 sierpnia 2026 | Koniec ciszy: trzy commity na main i tag v2026.4, który obejmuje czerwcowy MySQL 8.4 |
Pierwsza rzecz, która zaskakuje przy porównaniu obu tagów: v2026.3 nie jest następcą v7.0.85. GitHub opisuje relację tych gałęzi jako diverged, 35 commitów w przód i 3 w tył. v2026.3 jest starsze o dwa i pół miesiąca. To dwie równoległe linie, a nie jedna oś czasu, i firma siedząca na 7.0.85 nie „została w tyle” o jedno wydanie, tylko stoi na innej gałęzi.
Druga, i tu tekst zdążył się zdezaktualizować: w chwili pisania ostatni commit pochodził z 17 czerwca, czyli od dziesięciu tygodni. Cisza skończyła się nazajutrz. 27 i 28 sierpnia weszły trzy commity i tag v2026.4, a to znaczy, że dziesięć tygodni przerwy w tym repozytorium nie jest jeszcze dowodem na porzucenie projektu. Warto o tym pamiętać przy następnej takiej ciszy.
Co jest w v2026.3
To wydanie techniczne, nie funkcjonalne. Nie ma w nim ani jednej nowej funkcji PIM: żadnego nowego typu atrybutu, żadnej zmiany w regułach, w imporcie ani w API. Cała zawartość to podniesienie warstwy uruchomieniowej.
| Element | 7.0.85 | v2026.3 |
|---|---|---|
| PHP | 8.1 | 8.3 |
| MySQL | 8.0.30 | 8.0.34 |
| Elasticsearch (serwer) | 8.4.2 | 8.17.0 |
lcobucci/jwt | ^4.2 | ^5.2 |
| Obraz Node | 18 | 18 |
| Symfony | 5.4 | 5.4 |
Jedna z tych zmian była pilna i to ona tłumaczy całą operację. PHP 8.1 stracił wsparcie bezpieczeństwa 31 grudnia 2025 roku. Instalacja Akeneo Community stojąca na 7.0.x od stycznia 2026 działa na interpreterze, który nie dostaje już żadnych łatek. PHP 8.3 ma wsparcie bezpieczeństwa do 31 grudnia 2027, więc odświeżenie kupuje dwa lata.
Reszta zmian jest w tej samej kategorii: usunięcie przestarzałego uwierzytelniania mysql_native_password, poprawki zgodności DateTime::getLastErrors(), aktualizacja phpspec/prophecy zamiast wyciszania ostrzeżeń. Solidna, nudna robota utrzymaniowa.
Czego v2026.3 nie naprawiła
Tutaj zaczyna się część, której nie znajdziesz w notatkach wydania, a która decyduje o tym, jak długo taka instalacja pociągnie.
MySQL 8.0 skończył życie 30 kwietnia 2026. v2026.3 została otagowana 30 marca, miesiąc przed tą datą, z MySQL 8.0.34 w docker-compose.yml. Przejście na MySQL 8.4 LTS (wsparcie do 2032 roku) powstało w czerwcu, razem z nową klasą MySQL84Platform i zmianą w PimRequirements.php, ale przez 79 dni leżało poza jakimkolwiek wydaniem.
Domknęła to v2026.4 z 28 sierpnia, już po publikacji tego tekstu: docker-compose.yml ma tam mysql:8.4.9, a PimRequirements.php wymaga co najmniej 8.4.0 i dopuszcza wersje poniżej 9.0. Kto instaluje z najnowszego tagu, dostaje bazę ze wsparciem. Kto stoi na v2026.3, nadal nie, i to jest praktyczny wniosek z tej sekcji: przy aktualizacji celuj w v2026.4, nie w v2026.3.
Obraz Node w repozytorium to nadal akeneo/node:18. Node 18 wyszedł ze wsparcia 30 kwietnia 2025, ponad rok przed tym wydaniem. Dotyczy to warstwy budowania frontendu, nie środowiska produkcyjnego, ale to ta sama klasa problemu, którą refresh miał zamknąć.
Symfony zostało na 5.4. To wersja LTS z łatkami bezpieczeństwa do lutego 2029, więc nie jest to dziura, ale wsparcie dla błędów skończyło się w listopadzie 2024, a bieżąca linia Symfony to 8.x. Framework pod Akeneo Community jest cztery główne wersje za rynkiem i refresh go nie dotknął. Klient PHP Elasticsearcha także został przypięty na 7.11.0, przy serwerze podniesionym do 8.17.
Żadna z tych trzech rzeczy nie zmieniła się w v2026.4. To wydanie ma cztery commity: MySQL 8.4, backport poprawek z gałęzi 7.0, ustawienie strict_variables w środowisku testowym i jedną poprawkę błędu 500 na stronie tworzenia grupy.
Zdanie z README, które trzeba przeczytać przed aktualizacją
Razem z nową numeracją Akeneo dopisało do README politykę wersjonowania i jest ona zaskakująco dosłowna:
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.
Czyli: brak jakiejkolwiek gwarancji kompatybilności wstecznej między dowolnymi dwoma wydaniami. Zmiana łamiąca może wejść w każdym, także w tym, który wygląda na drobny. Rekomendacja producenta jest w tym samym miejscu i brzmi „przypnij dokładną wersję w composer.json”.
Dla wdrożenia produkcyjnego to zmiana reżimu pracy, nie detal. Przy SemVer da się przyjąć zasadę „łatki bierzemy od ręki, wersje główne planujemy”. Przy tej polityce każda aktualizacja jest projektem: wymaga przejrzenia zmian, testów regresyjnych na własnych integracjach i okna wdrożeniowego. Jest też druga uwaga w README, łatwa do przeoczenia: przejście z 7.x na nową numerację wymaga wcześniejszego zaaplikowania wszystkich migracji z gałęzi 7.0.
Czy to znaczy, że EOL został odwołany?
Nie do końca, a najczęściej powtarzana na rynku data dotyczy czegoś innego, niż się jej przypisuje.
30 września 2026 to data końca wsparcia dla Akeneo PIM 7.0 w wersjach PaaS (Flexibility) i on-premise. Strona z datami wsparcia Akeneo mówi wprost, że dotyczy wyłącznie tych edycji, a nie Community Edition, i dodaje osobne zdanie: „The Community Edition is continuously being supported by Akeneo”, z odesłaniem do repozytorium GitHub. Formalnie więc Community nigdy nie dostało własnej daty EOL, a wydanie v2026.3 jest z tym deklaratywnym stanowiskiem spójne.
Praktycznie sytuacja wygląda tak:
- w 2026 roku powstały trzy otagowane wydania CalVer:
2026-2(10 lutego),v2026.3(30 marca) iv2026.4(28 sierpnia), - najistotniejsza poprawka techniczna czekała na wydanie 79 dni, ale jest w tagu,
- gałąź 7.0 dostała w ciągu dwunastu miesięcy trzy wydania, z czego jedno zawierało pojedynczą poprawkę wyświetlania historii,
- w repozytorium wisi 374 otwarte zgłoszenia,
- producent nie deklaruje żadnego SLA i nie obiecuje kompatybilności.
To nie jest martwy projekt i po v2026.4 nie jest to już projekt bez rytmu: trzy wydania w roku da się założyć w planie utrzymania. Zostaje natomiast rzecz ważniejsza od tempa, bo producent nie obiecuje, że kolejne wydanie nie zepsuje Twojej instalacji. Różnica jest istotna, bo prowadzi do innej decyzji niż „migrujemy, bo się kończy”.
Co z tego wynika, jeśli masz Akeneo Community
Trzy sytuacje, trzy różne odpowiedzi.
Jesteś na 7.0.x i planowałeś migrację „bo EOL”. Presja jest mniejsza, niż zakładałeś, ale problem PHP 8.1 jest realny i nie zniknie sam. Aktualizacja do v2026.3 jest tańsza niż zmiana systemu i warto ją rozważyć zamiast wymiany PIM-u. Aktualizuj do v2026.4, nie do v2026.3: to pierwsza z nich przynosi MySQL 8.4, a druga zostawia bazę po EOL.
Rozważasz Akeneo Community do nowego wdrożenia. Tutaj nasza rekomendacja się nie zmienia: do nowego projektu odradzamy. Nie z powodu EOL i już nie z powodu tempa wydań, tylko z powodu polityki braku kompatybilności wstecznej: to ona zamienia każdą aktualizację w projekt, i to ona nie zmieniła się ani o słowo. Jeśli potrzebujesz self-hosted, warto porównać koszt utrzymania Community z Pimcore albo Ergonode, bo cała płatna linia Akeneo (Growth, Advanced, Premium) jest dziś dostępna wyłącznie w modelu SaaS.
Masz działające wdrożenie i nie chcesz go ruszać. To najczęstszy przypadek i najbardziej sensowny. Akeneo Community, które robi swoją robotę na katalogu kilkudziesięciu tysięcy indeksów, nie jest powodem do projektu migracyjnego. Jest powodem do zapewnienia sobie łatek bezpieczeństwa, których producent nie gwarantuje.
LTS dla Akeneo Community: co robimy jako Macopedia
Dla naszych klientów jesteśmy gotowi świadczyć usługę LTS dla wdrożeń Akeneo Community, niezależnie od tego, w jakim tempie wydania publikuje producent. Zakres jest następujący:
- Aktualizacje bezpieczeństwa. Monitorujemy podatności w całym drzewie zależności instalacji, nie tylko w samym Akeneo: Symfony, Twig, dompdf, phpseclib, aws-sdk, guzzle i pozostałe pakiety, przez które realnie wchodzi się do aplikacji. Łatki backportujemy do wersji, na której stoi klient, bez wymuszania skoku wersji PIM-u.
- Utrzymanie warstwy uruchomieniowej we wspieranych wersjach. PHP, MySQL i Elasticsearch, razem z pracą, której producent nie wydał w tagu. Dziś to obraz Node 18, Symfony 5.4 i klient Elasticsearcha przypięty na 7.11.0 przy serwerze 8.17.
- Kontrolowana ścieżka 7.0.x na v2026.x. Z migracjami z gałęzi 7.0 zaaplikowanymi w odpowiedniej kolejności i z testami regresyjnymi na integracjach klienta, bo przy braku gwarancji kompatybilności to one, a nie changelog, są dowodem, że aktualizacja jest bezpieczna.
- Przypięta wersja i przewidywalne okna. Zgodnie z rekomendacją z README, ale z naszym harmonogramem przeglądów, żeby aktualizacja była decyzją, a nie reakcją na komunikat.
Robimy to od 2012 roku na wdrożeniach PIM i e-commerce, jesteśmy Akeneo Registered Partner, a nasz zespół utrzymuje i rozwija instalacje Akeneo w firmach, dla których katalog produktowy jest systemem krytycznym.
Jeśli masz wdrożone Akeneo Community i chcesz wiedzieć, na czym dokładnie stoisz, napisz do nas. Zaczynamy od przeglądu: która wersja, jakie zależności, które z nich mają dziś znane podatności i co z tego wynika dla harmonogramu.
Podsumowanie
v2026.3 jest dobrą wiadomością i słabą podstawą do planowania naraz. Dobrą, bo Akeneo Community dostało PHP 8.3 i wyszło spod interpretera bez łatek, a rynek dostał sygnał, że projekt nie jest porzucony. Słabą, bo zostawiło bazę danych po EOL, a najważniejszą poprawkę poza tagiem na 79 dni.
Po v2026.4 połowa tego zarzutu upada: baza jest wspierana, wydanie jest trzecim w roku, a repozytorium żyje. Nie upada druga połowa i to ona decyduje: README wprost odmawia gwarancji kompatybilności wstecznej między dowolnymi dwoma wydaniami, więc plan utrzymania systemu krytycznego nadal nie ma się na czym oprzeć po stronie producenta.
Data 30 września 2026 dotyczy wersji PaaS i on-premise 7.0, nie Community, i warto przestać się nią straszyć. Realne pytanie jest inne: kto zapewni Twojej instalacji łatki bezpieczeństwa w tempie, które da się wpisać do harmonogramu.
Ekspertka w dziedzinie zarządzania danymi produktowymi (PIM), autorka podcastu „Akademia PIM”. Jej doświadczenie obejmuje zarówno perspektywę klienta, jak i agencji wdrożeniowej, co pozwala na skuteczne połączenie biznesowych potrzeb firm z technicznymi aspektami implementacji PIM. W Macopedia pełni rolę Project Managera i Analityka Biznesowego, a jej publikacje pomagają firmom lepiej zarządzać informacją produktową i usprawniać procesy operacyjne.