Exemple de changelog

1. O lansare SaaS de rutină

Cazul comun: câteva modificări vizibile pentru utilizator, fără migrare, fără dramă. E scurtă pentru că lansarea a fost mică, iar rezistarea la impulsul de a o umple este cea mai mare parte a abilității.

## 20 august 2026

### Nou
- Vizualizări salvate în inbox. Fixează un filtru o dată și
  refolosește-l din bara laterală.

### Îmbunătățit
- Sarcina de export raportează acum progresul în loc să pară
  blocată pe conturi mari.

### Corectat
- Membrii invitați nu mai văd un panou gol înainte de prima
  autentificare.

2. O lansare de API cu o deprecare

Cititorul unui changelog de API caută un singur lucru: dacă integrarea sa este pe cale să se strice, și cât timp mai are. Pune asta sus și dă-i o dată.

## Acme API 4.2 - 20 august 2026

### Modificări incompatibile
- `?page=` a fost eliminat pe toate endpointurile de listă.
  Folosește valoarea `nextCursor` din răspunsul anterior.
  `?page=` returnează 400 după 1 octombrie 2026.
  Pași de migrare: acme.example/docs/pagination

### Nou
- Webhook-urile pot fi limitate la un singur proiect.

### Îmbunătățit
- Endpointurile de listă răspund de aproximativ patru ori mai
  repede pe conturi cu peste 10.000 de înregistrări.

3. O lansare mobilă

Magazinele de aplicații afișează un câmp de noutăți trunchiat, iar recenzia poate ține un build zile întregi. Ambele fapte modelează intrarea.

## iOS 3.4.0 - 20 august 2026

Mod offline. Deschide, citește și redactează fără conexiune;
totul se sincronizează când revii online.

### Tot în această lansare
- Pornire mai rapidă pe dispozitive mai vechi.
- Corectată o blocare la deschiderea unui link partajat din Mail.

4. O corectare de securitate

Singura intrare în care a spune mai puțin este corect. Utilizatorii trebuie să știe că ar trebui să actualizeze; nimeni altcineva nu are nevoie de o descriere suficient de precisă pentru a ataca versiunea pe care încă nu au actualizat-o.

## 20 august 2026

### Securitate
- Am întărit modul în care sunt validate tokenurile de sesiune.
  Conturile pe instalări auto-găzduite ar trebui să actualizeze la
  4.2.1 sau ulterior. Raportat responsabil; fără dovezi de
  exploatare. Detalii: acme.example/security/2026-08

5. Cum arată una proastă

Fiecare linie de aici este reală ca formă, și fiecare linie este o greșeală:

## v2.3.7

- Îmbinat PR #482 din feature/inbox-refactor
- Actualizat lodash 4.17.20 -> 4.17.21
- Corectată o cursă de date în MembershipCache.resolve()
- Diverse corectări de erori și îmbunătățiri
- Refactorizat modelul SavedView (mulțumim, Dave!)

Ce au în comun cele bune

• Descriu un rezultat, nu o implementare. Un cititor care nu a văzut niciodată codul poate încă spune dacă intrarea îl afectează.
• Omit lucruri. Actualizările de dependențe, refactorizările, modificările CI și redenumirile interne sunt absente, iar acea absență este ce menține restul lizibil.
• Pun lucrul costisitor primul. Dacă ceva se strică, este primul titlu, cu o dată.
• Sunt datate într-un mod pe care cititorul îl poate folosi: un număr de versiune unde utilizatorii pot vedea versiuni, o dată unde nu pot.
• Sunt plictisitoare intenționat. Fără semne de exclamare, fără adjective de marketing, fără „suntem încântați să anunțăm”. Oamenii care citesc un changelog caută informație și se vor supăra pe orice le stă în cale.

Întrebări frecvente

Ce format ar trebui să folosească un changelog?

keepachangelog.com este cel mai apropiat lucru de un standard, iar numele secțiunilor sale (Added, Changed, Deprecated, Removed, Fixed, Security) sunt larg recunoscute. Contează mult mai puțin decât formularea din interiorul secțiunilor. Un format consistent cu intrări vagi este mai rău decât un format lejer cu unele specifice.

Cât de des ar trebui să publicăm?

În orice ritm care se potrivește lansărilor tale, și consecvent. Publicarea per lansare este cea mai simplă regulă. Gruparea unei luni de lansări într-o singură postare face fiecare modificare individuală mai greu de găsit mai târziu, care este exact momentul în care majoritatea oamenilor chiar citesc un changelog.

Ar trebui changelog-ul să stea pe site-ul nostru sau pe o pagină terță?

Pe site-ul tău dacă poți, pentru că acolo se acumulează traficul și valoarea de căutare, și pentru că un changelog pe domeniul altcuiva este la un link distanță de produsul tău în loc să fie parte din el. Acesta e argumentul pentru a-l servi ca un feed pe care îl randezi singur, în loc de o pagină găzduită la care faci link.

Utilizatorii chiar citesc changelog-uri?

O mică fracțiune le citește regulat, iar o fracțiune mult mai mare le caută în momentul în care ceva se schimbă sub ei. Al doilea grup este motivul pentru a scrie simptomul în loc de cauză: caută ce li s-a întâmplat, cu propriile lor cuvinte.

Lectură suplimentară: changelog vs. note de lansare, și Keep a Changelog, implementat cu adevărat.