Przykłady changeloga

1. Rutynowe wydanie SaaS

Typowy przypadek: garść zmian widocznych dla użytkownika, bez migracji, bez dramatu. Jest krótkie, bo wydanie było małe, a opieranie się pokusie rozdmuchania to większość umiejętności.

## 20 sierpnia 2026

### Nowe
- Zapisane widoki w skrzynce odbiorczej. Przypnij filtr raz i użyj
  go ponownie z paska bocznego.

### Ulepszone
- Zadanie eksportu zgłasza teraz postęp zamiast wyglądać na
  zawieszone na dużych kontach.

### Naprawione
- Zaproszeni członkowie nie widzą już pustego panelu przed
  pierwszym logowaniem.

2. Wydanie API z deprecacją

Czytelnik changeloga API szuka jednej rzeczy: czy jego integracja zaraz się zepsuje, i ile ma czasu. Umieść to na górze i podaj datę.

## Acme API 4.2 - 20 sierpnia 2026

### Zmiany łamiące kompatybilność
- `?page=` zostało usunięte na wszystkich endpointach list. Użyj
  wartości `nextCursor` z poprzedniej odpowiedzi.
  `?page=` zwraca 400 po 1 października 2026.
  Kroki migracji: acme.example/docs/pagination

### Nowe
- Webhooki mogą być ograniczone do jednego projektu.

### Ulepszone
- Endpointy list odpowiadają około czterokrotnie szybciej na
  kontach z ponad 10 000 rekordów.

3. Wydanie mobilne

Sklepy z aplikacjami pokazują obcięte pole nowości, a recenzja może wstrzymać build na dni. Oba te fakty kształtują wpis.

## iOS 3.4.0 - 20 sierpnia 2026

Tryb offline. Otwieraj, czytaj i redaguj bez połączenia;
wszystko synchronizuje się, gdy wrócisz online.

### Także w tym wydaniu
- Szybsze uruchamianie na starszych urządzeniach.
- Naprawiono awarię przy otwieraniu udostępnionego linku z Mail.

4. Poprawka bezpieczeństwa

Jedyny wpis, w którym mniej znaczy poprawnie. Użytkownicy muszą wiedzieć, że powinni zaktualizować; nikt inny nie potrzebuje opisu wystarczająco precyzyjnego, by zaatakować wersję, której jeszcze nie zaktualizowali.

## 20 sierpnia 2026

### Bezpieczeństwo
- Wzmocniono sposób walidacji tokenów sesji. Konta na instalacjach
  samodzielnie zarządzanych powinny zaktualizować do 4.2.1 lub
  nowszej. Zgłoszone odpowiedzialnie; brak dowodów wykorzystania.
  Szczegóły: acme.example/security/2026-08

5. Jak wygląda zły przykład

Każda linia tutaj jest prawdziwa co do kształtu, i każda linia to błąd:

## v2.3.7

- Zmergowano PR #482 z feature/inbox-refactor
- Zaktualizowano lodash 4.17.20 -> 4.17.21
- Naprawiono race condition w MembershipCache.resolve()
- Różne poprawki błędów i ulepszenia
- Zrefaktoryzowano model SavedView (dzięki Dave!)

Co mają wspólnego dobre

• Opisują rezultat, nie implementację. Czytelnik, który nigdy nie widział kodu, wciąż może stwierdzić, czy wpis go dotyczy.
• Pomijają rzeczy. Aktualizacje zależności, refaktoryzacje, zmiany CI i wewnętrzne zmiany nazw są nieobecne, i ta nieobecność sprawia, że reszta jest czytelna.
• Stawiają kosztowną rzecz na pierwszym miejscu. Jeśli coś się psuje, to pierwszy nagłówek, z datą.
• Są datowane w sposób, który czytelnik może wykorzystać: numer wersji tam, gdzie użytkownicy widzą wersje, data tam, gdzie nie widzą.
• Są celowo nudne. Bez wykrzykników, bez marketingowych przymiotników, bez "z przyjemnością ogłaszamy". Ludzie czytający changelog szukają informacji i będą urażeni wszystkim, co stoi na przeszkodzie.

Częste pytania

Jakiego formatu powinien używać changelog?

keepachangelog.com jest najbliższy standardowi, a nazwy jego sekcji (Added, Changed, Deprecated, Removed, Fixed, Security) są szeroko rozpoznawane. Ma to znacznie mniejsze znaczenie niż sposób pisania wewnątrz sekcji. Spójny format z niejasnymi wpisami jest gorszy niż luźny format z konkretnymi.

Jak często powinniśmy publikować?

W dowolnym rytmie pasującym do Twoich wydań, i konsekwentnie. Publikowanie na wydanie to najprostsza zasada. Grupowanie miesiąca wydań w jeden post utrudnia znalezienie później każdej pojedynczej zmiany, a to właśnie wtedy większość ludzi faktycznie czyta changelog.

Czy changelog powinien być na naszej stronie czy na stronie zewnętrznej?

Na Twojej stronie, jeśli możesz, ponieważ tam gromadzi się ruch i wartość wyszukiwania, i ponieważ changelog na czyjejś domenie jest o link dalej od Twojego produktu, a nie jego częścią. To argument za serwowaniem go jako feedu, który sam renderujesz, zamiast hostowanej strony, do której linkujesz.

Czy użytkownicy naprawdę czytają changelogi?

Niewielki odsetek czyta je regularnie, a znacznie większy szuka ich w momencie, gdy coś się pod nimi zmienia. Ta druga grupa jest powodem, by pisać objaw zamiast przyczyny: szukają tego, co im się przydarzyło, swoimi słowami.

Dalsza lektura: changelog kontra notatki wydania, i Keep a Changelog, faktycznie wdrożone.