WordPress 7.1 ma wyjść 19 sierpnia 2026 – w ostatni dzień WordCamp US w Phoenix. To środkowe wydanie w roku z trzema release’ami: 7.0 9 kwietnia (Contributor Day na WordCamp Asia), 7.1 19 sierpnia (zamknięcie WordCamp US) i 7.2 około 8 grudnia (tydzień State of the Word). Propozycja Jonathana Desrosiersa z grudnia 2025 przywraca projekt do trzech majorów rocznie po dwóch wydaniach w 2025 i kontynuuje model premiery na scenie, który 6.9 znormalizował w grudniu 2025.
Zmiana architektoniczna to przypięcie, nie kadencja
Trzy wydania rocznie nie są nowe – to długoletni baseline WordPressa. Nowe jest to, że każda data jest zakotwiczona w flagship event, a nie w sygnale gotowości funkcji. Daty Beta 1 i RC liczy się wstecz od eventu: 7.1 potrzebuje Beta 1 1 lipca i RC1 29 lipca, żeby bezpiecznie zrobić premierę 19 sierpnia. Zespół release’owy optymalizuje teraz pod trafienie w kalendarz, a nie pod zasadę „pociąg odjeżdża, gdy jest pełny”.
To znacząca zmiana bodźców. Wydania sterowane kalendarzem idą na konkretny kompromis: funkcje, które nie przejdą bramek, spadają do następnego majora – cztery miesiące później – a funkcje, które prawie zdążą, wychodzą z ostrzejszymi krawędziami niż w reżimie „wydamy, gdy będzie gotowe”. Oba zachowania widać już w Chrome, Firefoxie czy Linux kernel – i oba są wykonalne, o ile downstream wie, w jakim trybie działa projekt.
Co to oznacza dla stron i pluginów
Dla właścicieli stron praktyczny efekt jest prosty: okna upgrade’u są przewidywalne z rocznym wyprzedzeniem. Przy nietrywialnej flocie WordPressa można już dziś wpisać w kalendarz 9 kwietnia, 19 sierpnia i 8 grudnia oraz zaplanować wokół nich capacity na testy. Minor release’y między majorami nadal będą się pojawiać, ale powierzchnia breaking changes porusza się według przewidywalnego harmonogramu.
Dla autorów pluginów zmiana jest ostrzejsza. Czteromiesięczna kadencja majorów oznacza twardą górną granicę dla tego, jak długo deprecations mogą wisieć, zanim staną się usunięciami, oraz wąskie okno na wypuszczenie aktualizacji kompatybilności przed premierą majora. Jeśli CI pluginu nie testuje cotygodniowo wersji trunk, release 19 sierpnia jest terminem, do którego ta luka musi się zamknąć. To ta sama dyscyplina operacyjna, którą blocking gates wymuszają w pipeline’ach contentowych – zrobić z harmonogramu constraint systemu, a nie ludzką deklaracją.
Ciche zastrzeżenie w propozycji
Desrosiers wyraźnie zaznacza, że nie ma wymogu podróżowania, żeby być w zespole release’owym – komunikacja zostaje na Slacku. To ważne, bo wiązanie premier z eventami ryzykuje ustawienie projektu wokół osób, które mogą polecieć do Azji, Phoenix albo na State of the Word. To doprecyzowanie utrzymuje pipeline contributorów otwarty, nawet gdy moment marketingowy dzieje się na scenie.
Grudniowa data 7.2 jest też oznaczona jako najmniej elastyczna z trzech, bo Black Friday, Cyber Monday i święta końca roku ściskają okno testów. To będzie prawdopodobnie pierwszy test, czy przypięcie do eventów przetrwa realny konflikt harmonogramu.
Krótka wersja
WordPress 7.1 na 19 sierpnia to nie tylko data – to drugi dowód modelu, w którym kalendarz prowadzi wydanie, a nie gotowość diffu. Jeśli prowadzisz WordPressa w skali albo piszesz pluginy dla takich stron, plan upgrade’ów na 2026 praktycznie pisze się dziś sam.