Ktoś zrobił galerię ze PHP maintenance pages z dzisiaj. Lista jest stale aktualizowana i można zgłaszać samemu, już ze 2

@sireplama Większość serwisów tak naprawdę wyłączyła się na wszelki wypadek. Ja wgl do teraz myślałem, że Hejto stało w całości na NextJS ale dopiero co zrobili posta, że update już zrobiony. Z tego co kojarzę z innego posta to backend Hejto stoi na AWS albo innym podobnym serverless i tam podmiana wersji PHP nie potrwała by długo. A skoro zrobili to tak szybko tzn, że wcześniej backend musiał stać na wersji niewiele niżej i nie trzeba było zmieniać nic w kodzie.

Alternatywnie administracja Hejto zwyczajnie robi sobie jaja i nigdy na PHP nie stała ale zawsze to opcja aby pośmiać się z Wykopu xD.

@dolitd ma to sens...

@Catharsis 

Alternatywnie administracja Hejto zwyczajnie robi sobie jaja i nigdy na PHP nie stała ale zawsze to opcja aby pośmiać się z Wykopu xD.

Dobry trolling

@sireplama Widać Hejto miało już w miarę aktualną wersję.

W przypadku takich łatek sprawa zwykle wygląda tak, że mają podział na cały release (x.), potem "duże patche" (x.y) i na końcu małe łatki (x.y.z). I teraz:

• Jeśli aktualizujesz tylko małą łatką to wystarczy zerknąć w patch notes, ewentualnie przetestować w przypadku naprawdę krytycznych systemów. Ale zwykle 5 minut i gotowe.

• Jeśli aktualizujesz o średnią wersję to zwykle masz do przeczytania długi spis zmian, warto sprawdzić kompatybilność wtyczek, innych systemów i sprawdzić na teście. Ale też zwykle jest to bezproblemowe.

• Natomiast jak zmieniasz dużą wersję to często zaczyna się zabawa - nowa wersja może wymagać również aktualizacji bazy danych, część wtyczek może nie działać zupełnie (ale mają nowsze alternatywy), sposób zapisu czy szyfrowania danych może się zmieniać (więc np. trzeba regenerować certyfikaty). Ogółem za każdym razem jest wtedy konieczna dokładna analiza i raczej zaczyna się od aktualizacji na teście - tutaj nie ma już po prostu "ryzyka awarii". Jeśli zrobisz takiego patcha bez przygotowania to coś padnie niemal na pewno

No i teraz mamy taki PHP, system gdzie nawet duże firmy hostingowe często oferują wsparcie dla wersji 5 czy 6. Firmy utrzymujące się same mogą często siedzieć na jeszcze starszych (duże aktualizacje są upierdliwe, jak masz mały zespół i wymóg uptime to często kończy się działaniem na sofcie pisanym przez dinozaury).

Problem istnieje na pewno od 5.4 (nie jest tak, że wcześniej go nie ma, po prostu nie sprawdzali), aktualizacje ("małe łatki) wydano od 8.2 do 8.5 oraz 7.4 (gdzie wydali tylko kod łatający problem).

Teraz wystarczy, że ktoś miał wersję 7.2 (jedna z bardzo popularnych) i ma wybór pomiędzy zmianą wersji do ósemki, albo updatem do 7.4 i kompilowaniem własnej łatki. Obie opcje dość długotrwałe i z ryzykiem.

A jak ma 5.2 czy 5.6 (które też są mocno popularne)? No to jest w dupie. Oficjalnej łatki brak, przejazd przez 3 duże wersje to mnóstwo roboty i aktualizacje innych systemów, samemu to trzeba by pisać całego patcha albo remediację ("zabezpieczenie" przez np. dodanie filtrów ruchu).

Wykop znając życie utknął właśnie na 5.x. Nie wiadomo czy się nie wyrobili, czy po prostu olali sprawę (ogłoszenie że będzie łata wyszło chyba dopiero dziś). Ale tak czy owak - pewnie właśnie walczą z różnymi dziwnymi babolami bo po każdej aktualizacji nie działa to czy tamto.

Disclaimer: Webdev to nie moja działka więc powyżej mogą być jakieś nieścisłości, ale zasada działania aktualizacji jest uniwersalna.

@Aramil brzmi rozsądnie...

@Aramil Zasadniczo to po prostu opisałeś czym jest SemVer: https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes

2. MINOR version when you add functionality in a backward compatible manner

3. PATCH version when you make backward compatible bug fixes

@Catharsis No tak. Dokładniej to opisałem co wynika z tego standardu.

@Gustawff mialem to samo napisać xD

@Gustawff Z tego co wiem to GOG nie zarabia na siebie zbyt dużo to pewnie dział IT też nie jest imponujący.

@Catharsis XD