There is a newer version available: Svenska 1.1.0

Håll en ändringslogg

Låt inte dina vänner slänga in en git logs i CHANGELOG™

Version 0.3.0

Vad är en ändringslogg?

En ändringslogg är en fil innehållandes en sammanfattad, kronologiskt ordnad lista över ändringar för varje version av ett projekt.

# 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

Vad är meningen med en ändringslogg?

För att göra det enkelt för användare och medarbetare att se exakt vilka viktiga ändringar som har gjorts mellan varje utgåva (eller version) av projektet.

Varför ska jag bry mig?

Därför att mjukvaruverktyg är för människor. Om du inte bryr dig, varför bidrar du till öppen källkod? Visst finns det väl någon del i din vackra hjärna som bryr sig.

Jag pratade med Adam Stacoviak och Jerod Santo från podcasten The Changelog (passande, eller hur?) om varför ansvariga och bidragsgivare bör bry sig, och motiveringen bakom detta projekt. Om du kan avvara lite tid (1:06), rekommenderar jag att lyssna på det.

Vad gör en bra ändringslogg?

Jag är glad att du frågade.

En bra ändringslogg håller sig till dessa principer:

Den är skapad för människor, inte maskiner, så läsbarhet är avgörande.
Lätt att länka till valfri sektion (därav Markdown framför klartext).
En undersektion per version.
Listar utgåvor i omvänd kronologisk ordning (nyast högst upp).
Anger alla datum på formatet YYYY-MM-DD (exempel: 2012-06-02 för 2:a juni 2012). Det är internationellt, förnuftigt och språkoberoende.
Anger uttryckligen om projektet följer Semantisk versionshantering.
Varje version bör:
- Ange datum då utgåvan släpptes på formatet angivet ovan.
- Gruppera ändringar för att beskriva deras inverkan på projektet enligt följande:
- Added för nya funktioner.
- Changed för ändringar på existerande funktionalitet.
- Deprecated för tidigare stabila funktioner som tas bort i nästa utgåva.
- Removed för funktioner tidigare markerade som Deprecated som tas bort i denna version.
- Fixed för buggfixar.
- Security för att uppmana användare att uppgradera vid fall av sårbarheter.

Hur kan jag minimera den insats som krävs?

Ha alltid en sektion kallad "Unreleased" högst upp för att hålla reda på alla ändringar.

Detta tjänar två syften:

Folk kan se vilka ändringar som kan förväntas i kommande utgåvor
Vid lansering behöver du bara ändra "Unreleased" till versionsnumret och lägga till en ny "Unreleased" högst upp.

Vad får änglarna att gråta?

Okej...låt oss gå genom det.

Dumpa ut en diff från commit-loggen. Gör helt enkelt inte så, du hjälper ingen.
Inte betona deprecations. När användare uppgraderar från en version till en annan ska det vara smärtsamt uppenbart om något förväntas gå sönder.
Datum i region-specifikt format. I USA lägger folk månaden först ("06-02-2012" för 2:a juni 2012, vilket bara är konstigt), medan många andra runt om i världen skriver "2 June 2012" men uttalar det annorlunda. "2012-06-02" fungerar logiskt från största till minsta, inte överlappar på ett tvetydligt sätt med andra datumformat, och det är en ISO-standard. Dessutom är det rekommenderat datumformat för ändringsloggar.

Det finns mer. Hjälp mig att samla tårarna från änglarna genom att öppna en issue eller en pull-förfrågan.

Finns det ett standardformat på ändringsloggar?

Tyvärr inte. Men lugn. Jag vet att du frustrerad kommer att rusa iväg för att hitta den där länken till GNU:s format för ändringsloggar, eller den två stycken långa GNU NEWS-filen med "guideline". Stilguiden från GNU är en bra start, men den är tyvärr allt för naiv. Det är inget fel med att vara naiv, men när människor behöver vägledning är det inte speciellt hjälpsamt. Speciellt när det är många olika situationer och specialfall att hantera.

Detta projekt innehåller vad jag hoppas kommer att bli en bättre filkonvention för CHANGELOG. Jag tror inte att status quo är tillräckligt bra, och jag tror att vi tillsammans kan komma fram till en bättre konvention om vi försöker att plocka ut bra erfarenheter från riktiga mjukvaruprojekt. Titta runt och kom ihåg att diskussioner och förbättringsförslag är välkomna!

Vad bör filen med ändringsloggen heta?

Tja, om du inte kan lista ut det från exemplen ovan är CHANGELOG.md den bästa konvention hittills.

En del projekt använder också HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, etc.

Det är en verklig röra. Alla dessa namn gör det bara svårare för människor att hitta.

Varför kan folk inte bara använda en diff från `git log`?

Eftersom logg-diffar av naturen är fulla med brus. Det kan inte ens användas för att göra en lämplig ändringslogg ens i ett hypotetiskt projekt drivet av perfekta människor som aldrig skriver fel, aldrig glömmer att checka in nya filer eller aldrig glömmer någon del av en refaktorering. Syftet med en commit är att dokumentera ett enskilt steg i processen då koden utvecklas från ett tillstånd till ett annat. Syftet med en ändringslogg är att dokumentera de anmärkningsvärda skillnaderna mellan dessa tillstånd.

På samma sätt som det är skillnad mellan bra kommentarer och själva koden, är det skillnad mellan ändringsloggen och commit-loggen: en beskriver varför och den andra hur.

Kan ändringsloggar bli automatiskt tolkade?

Det är svårt då människor följer vitt olika format och filnamn.

Vandamme är en Ruby gem skapad av gruppen bakom Gemnasium som tolkar många (men inte alla) ändringsloggar för öppen källkod.

Varför alternerar du mellan att skriva det som "CHANGELOG" och "ändringslogg"?

"CHANGELOG" är namnet på själva filen. Det sticker ut lite, men det är en historisk konvention använt i många öppna källkodsprojekt. Andra exempel på liknande filer är README, LICENSE och CONTRIBUTING.

De stora bokstäverna i namnen (som gjorde att de i äldre operativsystem hamnade högst upp) används för att dra uppmärksamhet till dem. Då de är viktig metadata om projektet borde de vara användbara för att alla som vill använda eller bidra till det, ungefär som open source project badges.

När jag refererar till "ändringslogg" pratar jag om syftet med denna fil: att logga ändringar.

Hur är det med brådskande utgåvor ("yanked")?

Brådskande utgåvor är versioner som måste släppas p.g.a. alvarliga buggar eller säkerhetsproblem. Oftast brukar dessa versioner inte ens finnas med i ändringsloggarna. De borde det. Så här borde du visa dem:

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

Taggen [YANKED] står ut av en anledning, det är viktigt för människor att se den. Då den är omsluten med hakparenteser är det också lättare för ett program att tolka.

Borde du någonsin förändra en ändringslogg?

Självklart. Det finns alltid en bra anlending att förbättra en ändringslogg. Jag öppnar regelbundet pull requests för att lägga till saknade utgåvor för öppna källkodsprojekt som inte tar hand om sin ändringslogg.

Det kan också hända att du upptäcker att du glömt att ta upp en icke bakåtkompatibel förändring i en version. I sådana fall är det självklart viktigt att uppdatera din ändringslogg.

Hur kan jag bidra?

Detta dokument är inte sanningen, det är en noga övervägd åsikt tillsammans med information och exempel jag har samlat på mig. Även om jag tillhandahåller en CHANGELOG i min GitHub repo, har jag avsiktligt inte skapat en egentlig utgåva eller en tydlig lista med regler att följa (som t.ex. SemVer.org gör).

Detta beror på att jag vill att vår gemenskap ska nå samförstånd. Jag tror att diskussionen är lika viktig som slutresultatet.

Så välkomna att diskutera.