Vzdržujte dnevnik sprememb

Ne dopustite, da vaši prijatelji odlagajo dnevnike Git v dnevnike sprememb.

Različica 1.1.0 
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- v1.1 Brazilian Portuguese translation.
- v1.1 German Translation
- v1.1 Spanish translation.
- v1.1 Italian translation.
- v1.1 Polish translation.
- v1.1 Ukrainian translation.

### Changed

- Use frontmatter title & description in each language version template
- Replace broken OpenGraph image with an appropriately-sized Keep a Changelog 
  image that will render properly (although in English for all languages)
- Fix OpenGraph title & description for all languages so the title and 
description when links are shared are language-appropriate

### Removed

- Trademark sign previously shown after the project description in version 
0.3.0

## [1.1.1] - 2023-03-05

### Added

- Arabic translation (#444).
- v1.1 French translation.
- v1.1 Dutch translation (#371).
- v1.1 Russian translation (#410).
- v1.1 Japanese translation (#363).
- v1.1 Norwegian Bokmål translation (#383).
- v1.1 "Inconsistent Changes" Turkish translation (#347).
- Default to most recent versions available for each languages.
- Display count of available translations (26 to date!).
- Centralize all links into `/data/links.json` so they can be updated easily.

### Fixed

- Improve French translation (#377).
- Improve id-ID translation (#416).
- Improve Persian translation (#457).
- Improve Russian translation (#408).
- Improve Swedish title (#419).
- Improve zh-CN translation (#359).
- Improve French translation (#357).
- Improve zh-TW translation (#360, #355).
- Improve Spanish (es-ES) transltion (#362).
- Foldout menu in Dutch translation (#371).
- Missing periods at the end of each change (#451).
- Fix missing logo in 1.1 pages.
- Display notice when translation isn't for most recent version.
- Various broken links, page versions, and indentations.

### Changed

- Upgrade dependencies: Ruby 3.2.1, Middleman, etc.

### Removed

- Unused normalize.css file.
- Identical links assigned in each translation file.
- Duplicate index file for the english version.

## [1.1.0] - 2019-02-15

### Added

- Danish translation (#297).
- Georgian translation from (#337).
- Changelog inconsistency section in Bad Practices.

### Fixed

- Italian translation (#332).
- Indonesian translation (#336).

## [1.0.0] - 2017-06-20

### Added

- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
- "How do I make a changelog?" section.
- "Frequently Asked Questions" section.
- New "Guiding Principles" sub-section to "How do I make a changelog?".
- Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
- German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
- Italian translation from [@azkidenz](https://github.com/azkidenz).
- Swedish translation from [@magol](https://github.com/magol).
- Turkish translation from [@emreerkan](https://github.com/emreerkan).
- French translation from [@zapashcanon](https://github.com/zapashcanon).
- Brazilian Portuguese translation from [@Webysther](https://github.com/Webysther).
- Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
- Russian translation from [@aishek](https://github.com/aishek).
- Czech translation from [@h4vry](https://github.com/h4vry).
- Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
- Korean translation from [@pierceh89](https://github.com/pierceh89).
- Croatian translation from [@porx](https://github.com/porx).
- Persian translation from [@Hameds](https://github.com/Hameds).
- Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).

### Changed

- Start using "changelog" over "change log" since it's the common usage.
- Start versioning based on the current English version at 0.3.0 to help
  translation authors keep things up-to-date.
- Rewrite "What makes unicorns cry?" section.
- Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
  scenario.
- Improve "Commit log diffs" sub-section to further argument against
  them.
- Merge "Why can’t people just use a git log diff?" with "Commit log
  diffs".
- Fix typos in Simplified Chinese and Traditional Chinese translations.
- Fix typos in Brazilian Portuguese translation.
- Fix typos in Turkish translation.
- Fix typos in Czech translation.
- Fix typos in Swedish translation.
- Improve phrasing in French translation.
- Fix phrasing and spelling in German translation.

### Removed

- Section about "changelog" vs "CHANGELOG".

## [0.3.0] - 2015-12-03

### Added

- RU translation from [@aishek](https://github.com/aishek).
- pt-BR translation from [@tallesl](https://github.com/tallesl).
- es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).

## [0.2.0] - 2015-10-06

### Changed

- Remove exclusionary mentions of "open source" since this project can
  benefit both "open" and "closed" source projects equally.

## [0.1.0] - 2015-10-06

### Added

- Answer "Should you ever rewrite a change log?".

### Changed

- Improve argument against commit logs.
- Start following [SemVer](https://semver.org) properly.

## [0.0.8] - 2015-02-17

### Changed

- Update year to match in every README example.
- Reluctantly stop making fun of Brits only, since most of the world
  writes dates in a strange way.

### Fixed

- Fix typos in recent README changes.
- Update outdated unreleased diff link.

## [0.0.7] - 2015-02-16

### Added

- Link, and make it obvious that date format is ISO 8601.

### Changed

- Clarified the section on "Is there a standard change log format?".

### Fixed

- Fix Markdown links to tag comparison URL with footnote-style links.

## [0.0.6] - 2014-12-12

### Added

- README section on "yanked" releases.

## [0.0.5] - 2014-08-09

### Added

- Markdown links to version tags on release headings.
- Unreleased section to gather unreleased changes and encourage note
  keeping prior to releases.

## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain.
- README now contains answers to common questions about CHANGELOGs.
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?".

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.1...HEAD
[1.1.1]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.3.0...v1.0.0
[0.3.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...v0.3.0
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.8...v0.1.0
[0.0.8]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.7...v0.0.8
[0.0.7]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.6...v0.0.7
[0.0.6]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...v0.0.6
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

Kaj je dnevnik sprememb?

Dnevnik sprememb (angl. changelog) je datoteka, ki vsebuje kuriran, kronološko urejen seznam opaznih sprememb za vsako različico projekta.

Zakaj vzdrževati dnevnik sprememb?

Za poenostavitev, da uporabniki in sodelavci natančno vidijo, katere opazne spremembe so bile narejene med vsako izdajo (ali različico) projekta.

Kdo potrebuje dnevnik sprememb?

Ljudje to potrebujejo. Ne glede na to, ali so uporabniki ali razvijalci, so končni uporabniki programske opreme ljudje, ki jim je mar, kaj je v programski opremi. Ko se programska oprema spremeni, ljudje želijo vedeti, zakaj in kako.

Kako naredim dober dnevnik sprememb?

Smernice

  • Dnevniki sprememb so za ljudi, ne za stroje.
  • Obstajati mora vnos za vsako posamezno različico.
  • Enake vrste sprememb je treba združiti.
  • Različice in razdelki morajo biti povezljivi.
  • Najnovejša različica je na prvem mestu.
  • Prikaže se datum izdaje vsake različice.
  • Navedite, ali sledite Semantičnim različicam.

Vrste sprememb

  • Dodano (angl. Added) za nove lastnosti.
  • Spremenjeno (angl. Changed) za spremembe obstoječe funkcionalnosti.
  • Opuščeno (angl. Deprecated) za lastnosti, ki bodo kmalu odstranjene.
  • Odstranjeno (angl. Removed) za zdaj odstranjene lastnosti.
  • Popravljeno (angl. Fixed) za morebitne popravke napak.
  • Varnost (angl. Security) v primeru ranljivosti.

Kako lahko zmanjšam trud, potreben za vzdrževanje dnevnika sprememb?

Na vrhu imejte razdelek Neobjavljeno, če želite slediti prihajajočim spremembam.

To ima dva namena:

  • Ljudje lahko vidijo, kakšne spremembe lahko pričakujejo v prihajajočih izdajah
  • Ob izdaji lahko premaknete razdelek sprememb Neobjavljeno v nov razdelek različice izdaje.

Ali so lahko dnevniki sprememb slabi?

Da. Tukaj je nekaj načinov, kako so lahko manj koristni.

Razlike dnevnika potrditev (angl. diffs)

Uporaba razlik dnevnika potrditev kot dnevnikov sprememb je slaba ideja: polni so navlake. Stvari, kot so potrditve združitev, potrditve z nejasnimi naslovi, spremembe dokumentacije itd.

Namen potrditve je dokumentirati korak v razvoju izvorne kode. Nekateri projekti imajo potrditve čiste, nekateri ne.

Namen vnosa v dnevnik sprememb je dokumentirati razlike, ki so vredne omembe, pogosto v več potrditvah, da jih sporočite na jasen način končnim uporabnikom.

Ignoriranje opustitve

Ko ljudje nadgradijo z ene različice na drugo, bi moralo biti boleče jasno, kdaj se bo kaj zalomilo. Moralo bi biti mogoče nadgraditi na različico, ki navaja opustitve, odstraniti, kar je zastarelo, in nato nadgraditi na različico, kjer opustitve postanejo odstranitve.

Če ne naredite nič drugega, v vašem dnevniku sprememb navedite opustitve, odstranitve in katere koli prelomne spremembe.

Zavajujoči datumi

Območni formati datumov se po svetu razlikujejo in pogosto je težko najti človeku prijazen format datuma, ki se zdi intuitiven vsem. Prednost datumov, oblikovanih kot 2017-07-17 je, da sledijo vrstnemu redu od največje do najmanjše enote: leto, mesec in dan. Ta oblika se tudi ne prekriva na dvoumne načine z drugimi formati datumov, za razliko od nekaterih območnih formatov, ki zamenjajo položaj številk meseca in dneva. Ti razlogi in dejstvo, da je ta oblika datuma standardni ISO, so to, kar naredijo to priporočeni format datuma za vnose v dnevnik sprememb.

Nedosledne spremembe

Dnevnik sprememb, ki omenja samo nekatere spremembe, je lahko enako nevaren, kot če nimate dnevnika sprememb. Čeprav mnoge spremembe morda niso pomembne - na primer, odstranitve enega samega presledka morda ne bo treba zabeležiti v vseh primerih - je pa treba vse pomembne spremembe omeniti v dnevniku sprememb. Z nedoslednim uveljavljanjem sprememb lahko vaši uporabniki zmotno mislijo, da je dnevnik sprememb edini vir resnice. Moral bi biti. Z veliko močjo prihaja tudi velika odgovornost - imeti dober dnevnik sprememb pomeni imeti dosledno posodobljen dnevnik sprememb.

Pogosto zastavljena vprašanja

Ali obstaja standardna oblika dnevnika sprememb?

Niti ne. Obstaja stilski vodnik dnevnika sprememb GNU, ali pa "smernice" v dveh odstavkih dolgi datoteki GNU NEWS Oboje je neustrezno ali nezadostno.

Ta projekt cilja biti boljša konvencija dnevnika sprememb. Izhaja iz opazovanja dobrih praks v odprtokodni skupnosti in njihovega zbiranja.

Zdrava kritika, razprava in predlogi za izboljšave so dobrodošli.

Kako naj se imenuje datoteka dnevnika sprememb?

Poimenujte jo CHANGELOG.md. Nekateri projekti uporabljajo HISTORY, NEWS, ali RELEASES.

Čeprav je enostavno misliti, da ime vaše datoteke dnevnika sprememb ni tako pomembno, zakaj bi končnim uporabnikom otežili dosledno iskanje pomembnih sprememb?

Kaj pa GitHub Releases?

To je odlična pobuda. Releases je mogoče uporabiti za pretvorbo preprostih oznak Git (na primer oznaka z imenom v1.0.0) v bogate opombe ob izdaji z ročnim dodajanjem opomb izdaje ali pa lahko potegne sporočila anotiranih oznak Git in jih pretvori v opombe.

GitHub Releases ustvarijo neprenosljiv dnevnik sprememb, ki ga je mogoče prikazati le uporabnikom v kontekstu GitHuba. Mogoče jih je narediti zelo podobne formatu Keep a Changelog, vendar je ponavadi potrebno nekoliko več vpletenosti.

Trenutna različica izdaj GitHub tudi verjetno ni preveč odprta, da jo končni uporabniki odkrijejo, za razliko od tipičnih datotek z velikimi črkami (README, CONTRIBUTING itd.). Druga manjša težava je, da vmesnik trenutno ne ponuja povezav na dnevnike potrditev med vsako izdajo.

Ali je mogoče dnevnike sprememb samodejno razčleniti?

Težko je, ker ljudje sledijo zelo različnim formatom in imenom datotek.

Vandamme je Rubyjev gem, ustvarjen pri ekipi Gemnasium in razčlenjuje mnoge (vendar ne vse) dnevnike sprememb odprtokodnih projektov.

Kaj pa izvlečene (angl. yanked) izdaje?

Izvlečene izdaje so različice, ki jih je bilo treba umakniti zaradi resne napake ali varnostne težave. Pogosto se te različice sploh ne pojavijo v dnevnikih sprememb. Morale pa bi se. Prikazati bi jih morali tako:

## [0.0.5] - 2014-12-13 [YANKED]

Značka [YANKED] je v velikih črkah z razlogom. Pomembno je, da jo ljudje opazijo. Ker je obdana z oglatimi oklepaji, jo je tudi mogoče enostavneje programsko razčleniti.

Bi morali kdaj prepisati dnevnik sprememb?

Seveda. Vedno obstajajo dobri razlogi za izboljšanje dnevnika sprememb. Redno odpiram zahteve potegov, da dodam manjkajoče izdaje odprtokodnim projektom z nevzdrževanimi dnevniki sprememb.

Možno je tudi, da odkrijete, da ste pozabili obravnavati kritično spremembo v opombah za različico. Očitno je pomembno, da v tem primeru posodobite dnevnik sprememb.

Kako lahko prispevam?

Ta dokument ni resnica; to je moje skrbno pretehtano mnenje, skupaj z informacijami in primeri, ki sem jih zbral.

To je zato, ker želim, da naša skupnost doseže soglasje. Menim, da je razprava enako pomembna kot končni rezultat.

Zato vas prosim, da se oglasite.

Pogovori

Odšel sem na podcast The Changelog, da bi govoril o tem, zakaj bi morali vzdrževalci in sodelavci skrbeti za dnevnike sprememb, in tudi o motivacijah za tem projektom.