För en ändringslogg

Låt inte dina vänner slänga in git-loggar i ändringsloggar.

Version 1.0.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

Vad är en ändringslogg?

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

Vad är meningen med en ändringslogg?

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

Vem behöver en ändringslogg?

Alla behöver det. Oavsett om det är användare eller utvecklare, är alla slutanvändare av mjukvaran människor som bryr sig vad som finns i mjukvaran. När mjukvaran förändras vill folk veta varför och hur.

Hur gör jag en bra ändringslogg?

Riktlinjer

  • Ändringsloggar är för människor, inte maskiner.
  • Det bör finnas en post för varje enskild version.
  • Samma typ av ändringar bör grupperas.
  • Det bör vara möjligt att länka till versioner och sektioner.
  • Senaste versionen kommer först.
  • Datum då respektive version släpptes ska visas.
  • Notering att du följer Semantisk versionshantering.

Typer av ändringar

  • Added för nya funktioner.
  • Changed för ändringar på existerande funktionalitet.
  • Deprecated för funktionalitet som snart tas bort.
  • Removed för nu borttagen funktionalitet.
  • Fixed för alla buggfixar
  • Security i fall av sårbarheter.

Hur kan jag minimera den insats som krävs för att underhålla en ändringslogg?

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

Detta tjänar två syften:

  • Folk kan se vilka ändringar de kan förvänta sig i kommande utgåvor
  • Vid lansering behöver du bara flytta innehållet i sektionen Unreleased till en ny versionspost.

Kan ändringsloggar vara dåliga?

Ja, här är några exempel på då de är mindre användbara.

Diffar från incheckningsloggen.

Det är en dålig idé att använda incheckningsloggen som ändringslogg: de är fulla av brus. Saker så som merge-incheckningar, incheckningar med otydliga titlar, dokumentationsförändringar etc.

Syftet med en incheckning är att dokumentera ett steg i utvecklingen av källkoden. Vissa projekt städar upp bland incheckningarna, andra inte.

Syftet med en post i en ändringslogg är att dokumentera den noterbara skillnaden, oftast över flera incheckningar, för att kommunicera dessa tydligt till slutanvändaren.

Ignorera föråldrad funktionalitet (deprecations)

När användare uppgraderar från en version till en annan, ska det vara smärtsamt uppenbart när något förväntas gå sönder. Den bör vara möjligt att uppgradera till en version som listar föråldrad funktionalitet, ta bort dessa beroenden i sitt program, och sedan uppgradera till en version där den föråldrade funktionaliteten är borttagen.

Om du inte gör något annat, lista åtminstone föråldrad och borttagen funktionalitet samt förstörande förändringar i din ändringslogg.

Förvillande datum

Lokala datumformat varierar över hela världen, och det är ofta svårt att hitta ett användbart datumformat som känns intuitivt för alla. Fördelen med datumformat så som 2017-07-17 är att det följer storleksordningen från störst till minst: år, månad och dag. Detta format överlappar inte heller på ett tvetydligt sätt med andra datumformat, till skillnad från lokala format som kan växla positionen på månad och dag. Dessa anledningar tillsammans med det faktum att detta datumformat är en ISO-standard, gör att detta är rekommenderat format för ändringsloggar.

Vanliga frågor

Finns det ett standardformat på ändringsloggar?

Inte riktigt. GNU:s stilguide för ändringsloggar och den två stycke långa GNU NEWS-filen med "riktlinjer" finns. Båda är bristfälliga och otillräckliga.

Detta projekt har som mål att bli en bättre konvention för ändringsloggar. Det utgår från uppenbart goda praxis från öppen källkods-världen och sammanför dem.

Konstruktiv kritik, diskussion och förslag till förbättring är välkommen.

Vad bör filen med ändringsloggen heta?

Döp den till CHANGELOG.md. En del projekt använder HISTORY, NEWS eller RELEASES.

Även om det är lätt att tänka att det inte spelar så stor roll vad filen med ändringsloggar kallas, varför göra det svårare för dina slutanvändare att enkelt hitta de viktigaste ändringarna?

Hur är det med GitHub Releases?

Det är ett fantasiskt initiativ. Releases kan användas för att göra enkla git-taggar (t.ex. en tagg kallad v1.0.0) till formaterade versionsanteckningar genom att manuellt lägga till versionsanteckningar eller så kan den hämta meddelandena i kommenterade git-taggar och omvandla dessa till versionsanteckningar.

GitHub Releases skapar en icke porterbar ändringslogg som enbart kan visas för användare på GitHub. Det är möjligt att formatera det ungefär som på För en ändringslogg-formatet, men det tendera att bli lite mer invecklat.

Nuvarande version av GitHub releases är möjligtvis också lite svår att hitta för slutanvändare, till skillnad från filer med normalt stora bokstäver (README, CONTRIBUTING, etc.). Ett annat bekymmer är att användargränssnittet för närvarande inte erbjuder länkar till incheckningsloggar mellan olika versioner.

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 Gemnasium som tolkar många (men inte alla) ändringsloggar för öppen källkod.

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

Återtagna utgåvor är versioner som måste tas tillbaka på grund av allvarliga 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 att folk se det. Då den är omsluten med hakparenteser är det också lättare för ett program att tolka det.

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

Självklart. Det finns alltid en bra anledning 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.

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

Så tveka inte att kasta dig in i diskussionen.

Samtal

Jag var med i The Changelog podcast för att prata om varför förvaltare och bidragsgivare bör bry sig om ändringsloggar, och motiveringen bakom detta projekt.