---
title: Hold en changelog
description: Du skal ikke lade dine venner smide git logs i changelogs.
language: da
version: 1.1.0
---
.header
  .title
    %h1= current_page.data.title
    %h2= current_page.data.description

  = link_to data.links.changelog do
    Version
    %strong= current_page.metadata[:page][:version]

  %pre.changelog{ lang: "en" }= File.read("CHANGELOG.md")

.answers
  %h3#what
    %a.anchor{ href: "#what", aria_hidden: "true" }
    Hvad er en changelog?

  %p
    En changelog er en fil, der indeholder en organiseret, kronologisk
    sorteret liste af bemærkelsesværdige ændringer for hver version
    af et projekt.

  %h3#why
    %a.anchor{ href: "#why", aria_hidden: "true" }
    Hvorfor have en changelog?

  %p
    For at gøre det nemmere for brugere og bidragsydere at se præcist
    hvilke bemærkelsesværdige ændringer, der er lavet mellem hver
    udgivelse eller version af et projekt.

  %h3#who
    %a.anchor{ href: "#who", aria_hidden: "true" }
    Hvem skal bruge en changelog?

  %p
    Det skal folk. Om det er forbrugere eller udviklere, er slutbrugere
    mennesker, der bekymrer sig om, hvad der er i et stykke software. Når
    softwaren ændrer sig, vil folk gerne vide hvad, og hvordan.

.good-practices
  %h3#how
    %a.anchor{ href: "#how", aria_hidden: "true" }
    Hvordan laver jeg en god changelog?

  %h4#principles
    %a.anchor{ href: "#principles", aria_hidden: "true" }
    Retningslinjer

  %ul
    %li
      Changelogs er til <em>for mennesker</em>, ikke maskiner.
    %li
      Der skal være et indlæg for hver eneste version.
    %li
      Ens typer af ændringer skal grupperes.
    %li
      Versioner og sektioner skal være link-bare.
    %li
      Den seneste version står først.
    %li
      Udgivelsesdatoen for hver version vises.
    %li
      Nævn hvorvidt du følger #{link_to "Semantisk Versionering", data.links.semver}.

  %a.anchor{ href: "#types", aria_hidden: "true" }
  %h4#types Ændringstyper

  %ul
    %li
      %code Tilføjet (Added)
      til nye funktioner.
    %li
      %code Ændret (Dhanged)
      til rettelser i eksisterende funktionalitet.
    %li
      %code Udfaset (Deprecated)
      til funktioner, der fjernes snart.
    %li
      %code Fjernet (Removed)
      til fjernede funktioner.
    %li
      %code Rettet (Fixed)
      til fejlrettelser.
    %li
      %code Sikkerhed (Security)
      i tilfælde af sårbarheder.

.effort

  %h3#effort
    %a.anchor{ href: "#effort", aria_hidden: "true" }
    Hvordan kan jeg reducere indsatsen ved at opretholde en changelog?

  %p
    Hav en <code>Unreleased</code> sektion i toppen til kommende
    rettelser.

  %p Dette tjener to formål:

  %ul
    %li
      Folk kan se, hvilke rettelser de kan forvente i den kommende
      udgivelse
    %li
      Ved udgivelsen kan du flytte <code>Unreleased</code> sektionens
      rettelser ind i en ny versionssektion.

.bad-practices
  %h3#bad-practices
    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
    Kan changelogs være dårlige?

  %p Ja. Her er et par måder, de kan være mindre brugbare.

  %h4#log-diffs
    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
    Commit log diffs

  %p
    At bruge commit log differenser som changelog er en dårlig idé:
    De er fyldt med støj. Ting som merge-commits, commits med obskure titler,
    dokumentationsrettelser osv.

  %p
    Formålet med et commit er at dokumentere et trin i udviklingen af
    kildekoden. Nogle projekter rydder op i deres commits, andre gør
    ikke.

  %p
    Formålet med en changelog-indlæg er at dokumentere de bemærkelsesværdige
    forskelle, ofte fordelt over flere commits, for at formidle dem klart
    til slutbrugerene.

  %h4#ignoring-deprecations
    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
    At ignorere udfasninger

  %p
    Når folk opgraderer fra én version til en anden, skal det være helt
    tydeligt, hvorvidt noget vil gå i stykker. Det skal være muligt
    at opgradere til en version, der opsummerer udfasninger, fjerner
    gamle udfasniner, og opgradere til dén version, hvor udfasningerne
    bliver til oprydninger.

  %p
    Hvis du ikke gør andet, så notér udfasninger, fjernede funktioner
    og andre ødelæggende ændringer.


  %h4#confusing-dates
    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
    Forvirrende datoer

  %p
    Regionale dataformater er varierende i hele verden, og det er ofte
    besværligt at finde et læsbart datoformat, der føles intuitivt for alle
    Fordelen ved datoer formatteret som <code>2017-07-17</code> er at de
    følger rækkefølgen for største til mindste enhed: år, måned og dag.
    Dette format overlapper heller ikke på en tvetydig måde med andre
    datoformater, der ombytter måneden og daten. Af disse årsager, og
    det faktum at dette datoformat er en #{link_to "ISO standard", data.links.isodate},
    er dette det anbefalede datoformat for changelog-indlæg.

  %h4#inconsistent-changes
    %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" }
    Ukonsistente rettelser

  %p
    En changelog, der kun nævner nogle af ændringerne, kan være lige så
    farlig som ikke at have en changelog. Mens mange af ændringerne
    måske ikke er relevante - for eksempel er det ikke være nødvendigt at
    notere, at vi har fjernet et enkelt mellemrum - bør væsentlige
    ændringer være nævnt i changeloggen. Ved inkonsekvent at anvende
    ændringer, kan dine brugere fejlagtigt tro, at changelog er den
    eneste kilde til sandhed. Det bør den være. Med store
    magtbeføjelser følger store forpligtigelser. At have en god changelog
    er at have en konsekvent opdateret changelog.

  %aside
    Der er mere. Hjælp mig med at samle disse fælder ved at
    = link_to "åbne et issue", data.links.issue
    eller et pull-request.

.frequently-asked-questions
  %h3#frequently-asked-questions
    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
    Ofte stillede spørgsmål

  %h4#standard
    %a.anchor{ href: "#standard", aria_hidden: "true" }
    Er der et standard changelog-format?

  %p
    Ikke rigtig. Der er #{link_to "GNU changelog style guide", data.links.gnustyle},
    eller #{link_to "two-paragraph-long GNU NEWS file", data.links.gnunews}. De
    er begge utilstrækkelige eller uhensigtsmæssige.

  %p
    Dette projekt sigter efter at være
    = link_to "en bedre changelog konvention.", data.links.changelog
    Det kommer af at observere god praksis i opensource-verdenen
    og samle disse.

  %p
    Konstruktiv kritik diskussion og forbedringsforslag
    = link_to "er velkomne.", data.links.issue


  %h4#filename
    %a.anchor{ href: "#filename", aria_hidden: "true" }
    Hvad skal changelog-filen hedde?

  %p
    Kald den <code>CHANGELOG.md</code>. Nogle projekter bruger
    <code>HISTORY</code>, <code>NEWS</code> eller <code>RELEASES</code>.

  %p
    Selvom det er nemt at mene, at navnet på changelog-filen er
    irrelevant, hvorfor så gøre det sværere for dine slugbrugere
    at finde bemærkelsesværdige ændringer?


  %h4#github-releases
    %a.anchor{ href: "#github-releases", aria_hidden: "true" }
    Hvad med GitHub Releases?

  %p
    Det er et godt initiativ. #{link_to "Releases", data.links.github_releases} kan bruges
    til at gøre simple git tags (for eksempel, et tag <code>v1.0.0</code>)
    til fyldige udgivelsesnoter ved manuelt at tilføje noter til disse
    eller bruge en annoteret git-tag-besked som udgivelsesnoter.

  %p
    GitHub Releases laver en ikke-flytbar changelog, der kun kan vises
    til bruger i konteksten af GitHub. Det er muligt at få dem til at
    ligne Hold en changelog-formatet, men det har en tendens til at
    være lidt mere kompliceret.

  %p
    Den nuværende version af GitHub releases er, diskutérbart,
    ikke særligt synlig for slutbrugere, ikke lig de typiske
    kapitaliserede filer (<code>README</code>,
    <code>CONTRIBUTING</code>, osv.). Et andet mindre problem, er
    at interfacet ikke tilbyder links til commit logs mellem hvert
    release.

  %h4#automatic
    %a.anchor{ href: "#automatic", aria_hidden: "true" }
    Kan changelogs læses og fortolkes automatisk?

  %p
    Det er besværligt, fordi folk følger vidt forskellige formater
    og filnavne.

  %p
    #{link_to "Vandamme", data.links.vandamme} er en Ruby gem lavet af
    holdet bag Gemnasium, som læser og fortolker mange (men ikke
    alle) open source projekters changelogs.

  %h4#yanked
    %a.anchor{ href: "#yanked", aria_hidden: "true" }
    Hvad med tilbagetrukkede udgivelser?

  %p
    Tilbagetrukkede udgivelser er versioner, der er blevet trukket
    tilbage på grund af en seriøs fejl eller sikkerhedsbrist. Ofte
    vises disse versioner slet ikke i changelogs. Det bør de. Dette
    er hvordan du bør vise dem:

  %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>

  %p
    Notationen <code>[YANKED]</code>, er højlydt af en årsag: Det er
    vigtig information for folk. Siden den er pakket ind i klammer, er
    den nemmere at fortolke og læse systematiseret.


  %h4#rewrite
    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
    Bør man nogensinde omskrive en changelog?

  %p
    Klart! Der er altid gode grunde til at forbedre en changelog.
    Jeg åbner jævnligt pull-requests, der tilføjer manglende releases
    til open source projekter uden en vedligeholdt changelog.

  %p
    Det er også muligt, at du vil opdage at du har glemt at addressere
    en ødelæggende rettelse i noterne for en version. Det er selvfølgelig
    vigtigt at du opdaterer en changelog i disse tilfælde.


  %h4#contribute
    %a.anchor{ href: "#contribute", aria_hidden: "true" }
    Hvordan kan jeg hjælpe til?

  %p
    Dette dokument er ikke <strong>sandheden</strong>; det er min
    velovervejede mening sammen med information og eksempler jeg har
    samlet.

  %p
    Det er fordi, jeg gerne vil have at vores fællesskab når en konsensus.
    Jeg mener at diskussionen er lige så vigtig som slutresultatet.
  %p
    Så, <strong>#{link_to "vær med!", data.links.repo}</strong>

.press
  %h3 Samtaler
  %p
    Jeg var med i #{link_to "The Changelog podcast", data.links.thechangelog} for
    at snakke om, hvorfor vedligeholdere og bidragsydere bør bekymre sig
    om changelogs og også om motivationen bag dette projekt.