<commit_before>---
description: Håll en ändringslogg
title: Håll en ändringslogg
language: sv
version: 1.0.0
---

- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
- gemnasium = "https://gemnasium.com/"
- gh = "https://github.com/olivierlacan/keep-a-changelog"
- issues = "https://github.com/olivierlacan/keep-a-changelog/issues"
- semver = "http://semver.org/"
- shields = "http://shields.io/"
- thechangelog = "http://5by5.tv/changelog/127"
- vandamme = "https://github.com/tech-angels/vandamme/"
- iso = "http://www.iso.org/iso/home/standards/iso8601.htm"
- ghr = "https://help.github.com/articles/creating-releases/"

.header
  .title
    %h1 Håll en ändringslogg
    %h2 Låt inte dina vänner slänga in git-loggar i ändringsloggar.

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

  %pre.changelog= File.read("CHANGELOG.md")

.answers
  %h3#what
    %a.anchor{ href: "#what", aria_hidden: "true" }
    Vad är en ändringslogg?

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

  %h3#why
    %a.anchor{ href: "#why", aria_hidden: "true" }
    Vad är meningen med en ändringslogg?

  %p
    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.

  %h3#who
    %a.anchor{ href: "#who", aria_hidden: "true" }
    Vem behöver en ändringslogg?

  %p
    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.

.good-practices
  %h3#how
    %a.anchor{ href: "#how", aria_hidden: "true" }
    Hur gör jag en bra ändringslogg?

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

  %ul
    %li
      Ändringsloggar är <em>för människor</em>, inte maskiner.
    %li
      Det bör finnas en post för varje enskild version.
    %li
      Samma typ av ändringar bör grupperas.
    %li
      Det bör vara möjligt att länka till versioner och sektioner.
    %li
      Senaste versionen kommer först.
    %li
      Datum då respektive version släpptes ska visas.
    %li
      Notering att du följer #{link_to "Semantisk versionshantering", semver}.

  %a.anchor{ href: "#types", aria_hidden: "true" }
  %h4#types Typer av ändringar

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

.effort

  %h3#effort
    %a.anchor{ href: "#effort", aria_hidden: "true" }
    Hur kan jag minimera den insats som krävs för att underhålla en ändringslogg?

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

  %p Detta tjänar två syften:

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

.bad-practices
  %h3#bad-practices
    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
    Kan ändringsloggar vara dåliga?

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

  %h4#log-diffs
    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
    Diffar från incheckningsloggen.

  %p
    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.

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

  %p
    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.

  %h4#ignoring-deprecations
    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
    Ignorera föråldrad funktionalitet (deprecations)

  %p
    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.

  %p
    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.

  %h4#confusing-dates
    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
    Förvillande datum

  %p
    I USA lägger folk månaden först (<code>06-02-2012</code> för 2:a juni 2012),
    medan många andra runt om i världen skriver <code>2 June 2012</code> men
    uttalar det annorlunda. <code>2012-06-02</code> fungerar logiskt från störst
    till minst, överlappar inte på något tvetydligt sätt med andra datumformat,
    och är en #{link_to "ISO-standard", iso}. Dessutom är det rekommenderat
    datumformat för ändringsloggar.

  %aside
    Det finns mer. Hjälp mig att samla dessa antimönster genom att
    = link_to "skapa ett issue", issues
    eller en pull requests

.frequently-asked-questions
  %h3#frequently-asked-questions
    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
    Vanliga frågor

  %h4#standard
    %a.anchor{ href: "#standard", aria_hidden: "true" }
    Finns det ett standardformat på ändringsloggar?

  %p
    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.

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

  %p
    Konstruktiv kritik, diskussion och förslag till förbättring
    = link_to "är välkommen.", issues

  %h4#filename
    %a.anchor{ href: "#filename", aria_hidden: "true" }
    Vad bör filen med ändringsloggen heta?

  %p
    Döp den till <code>CHANGELOG.md</code>. En del projekt använder
    <code>HISTORY</code>, <code>NEWS</code> eller <code>RELEASES</code>.

  %p
    Ä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?

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

  %p
    Det är ett fantasiskt initiativ. #{link_to "Releases", ghr} kan användas
    för att göra enkla git-taggar (t.ex. en tagg kallad <code>v1.0.0</code>)
    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.

  %p
    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å
    Håll en ändringslogg-formatet, men det tendera att bli lite mer invecklat.

  %p
    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 (<code>README</code>, <code>CONTRIBUTING</code>, etc.).
    Ett annat bekymmer är att användargränssnittet för närvarande inte
    erbjuder länkar till incheckningsloggar mellan olika versioner.

  %h4#automatic
    %a.anchor{ href: "#automatic", aria_hidden: "true" }
    Kan ändringsloggar bli automatiskt tolkade?

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

  %p
    #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen
    #{link_to "Gemnasium", gemnasium} som tolkar många (men inte alla)
    ändringsloggar för öppen källkod.

  %h4#yanked
    %a.anchor{ href: "#yanked", aria_hidden: "true" }
    Hur är det med brådskande utgåvor ("yanked")?

  %p
    Brådskande utgåvor är versioner som måste släppas på grund av 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:

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

  %p
    Taggen <code>[YANKED]</code> 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.

  %h4#rewrite
    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
    Borde du någonsin förändra en ändringslogg?

  %p
    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.

  %p
    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.

  %h4#contribute
    %a.anchor{ href: "#contribute", aria_hidden: "true" }
    Hur kan jag bidra?

  %p
    Detta dokument är inte <strong>sanningen</strong>, det är en noga övervägd
    åsikt tillsammans med information och exempel jag har samlat på mig.

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

  %p
    Så tveka inte att <strong>#{link_to "kasta dig in i diskussionen", gh}</strong>.

.press
  %h3 Samtal
  %p
    Jag var med i #{link_to "The Changelog podcast", thechangelog}
    för att prata om varför förvaltare och bidragsgivare bör bry sig om
    ändringsloggar, och motiveringen bakom detta projekt.
<commit_msg>SV: Update the date paragraph according to #192<commit_after>---
description: Håll en ändringslogg
title: Håll en ändringslogg
language: sv
version: 1.0.0
---

- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
- gemnasium = "https://gemnasium.com/"
- gh = "https://github.com/olivierlacan/keep-a-changelog"
- issues = "https://github.com/olivierlacan/keep-a-changelog/issues"
- semver = "http://semver.org/"
- shields = "http://shields.io/"
- thechangelog = "http://5by5.tv/changelog/127"
- vandamme = "https://github.com/tech-angels/vandamme/"
- iso = "http://www.iso.org/iso/home/standards/iso8601.htm"
- ghr = "https://help.github.com/articles/creating-releases/"

.header
  .title
    %h1 Håll en ändringslogg
    %h2 Låt inte dina vänner slänga in git-loggar i ändringsloggar.

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

  %pre.changelog= File.read("CHANGELOG.md")

.answers
  %h3#what
    %a.anchor{ href: "#what", aria_hidden: "true" }
    Vad är en ändringslogg?

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

  %h3#why
    %a.anchor{ href: "#why", aria_hidden: "true" }
    Vad är meningen med en ändringslogg?

  %p
    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.

  %h3#who
    %a.anchor{ href: "#who", aria_hidden: "true" }
    Vem behöver en ändringslogg?

  %p
    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.

.good-practices
  %h3#how
    %a.anchor{ href: "#how", aria_hidden: "true" }
    Hur gör jag en bra ändringslogg?

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

  %ul
    %li
      Ändringsloggar är <em>för människor</em>, inte maskiner.
    %li
      Det bör finnas en post för varje enskild version.
    %li
      Samma typ av ändringar bör grupperas.
    %li
      Det bör vara möjligt att länka till versioner och sektioner.
    %li
      Senaste versionen kommer först.
    %li
      Datum då respektive version släpptes ska visas.
    %li
      Notering att du följer #{link_to "Semantisk versionshantering", semver}.

  %a.anchor{ href: "#types", aria_hidden: "true" }
  %h4#types Typer av ändringar

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

.effort

  %h3#effort
    %a.anchor{ href: "#effort", aria_hidden: "true" }
    Hur kan jag minimera den insats som krävs för att underhålla en ändringslogg?

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

  %p Detta tjänar två syften:

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

.bad-practices
  %h3#bad-practices
    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
    Kan ändringsloggar vara dåliga?

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

  %h4#log-diffs
    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
    Diffar från incheckningsloggen.

  %p
    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.

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

  %p
    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.

  %h4#ignoring-deprecations
    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
    Ignorera föråldrad funktionalitet (deprecations)

  %p
    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.

  %p
    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.

  %h4#confusing-dates
    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
    Förvillande datum

  %p
    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
    <code>2017-07-17</code> ä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
    #{link_to "ISO-standard", iso} gör att detta är rekommenderat
    format för ändringsloggar.

  %aside
    Det finns mer. Hjälp mig att samla dessa antimönster genom att
    = link_to "skapa ett issue", issues
    eller en pull requests

.frequently-asked-questions
  %h3#frequently-asked-questions
    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
    Vanliga frågor

  %h4#standard
    %a.anchor{ href: "#standard", aria_hidden: "true" }
    Finns det ett standardformat på ändringsloggar?

  %p
    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.

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

  %p
    Konstruktiv kritik, diskussion och förslag till förbättring
    = link_to "är välkommen.", issues

  %h4#filename
    %a.anchor{ href: "#filename", aria_hidden: "true" }
    Vad bör filen med ändringsloggen heta?

  %p
    Döp den till <code>CHANGELOG.md</code>. En del projekt använder
    <code>HISTORY</code>, <code>NEWS</code> eller <code>RELEASES</code>.

  %p
    Ä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?

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

  %p
    Det är ett fantasiskt initiativ. #{link_to "Releases", ghr} kan användas
    för att göra enkla git-taggar (t.ex. en tagg kallad <code>v1.0.0</code>)
    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.

  %p
    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å
    Håll en ändringslogg-formatet, men det tendera att bli lite mer invecklat.

  %p
    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 (<code>README</code>, <code>CONTRIBUTING</code>, etc.).
    Ett annat bekymmer är att användargränssnittet för närvarande inte
    erbjuder länkar till incheckningsloggar mellan olika versioner.

  %h4#automatic
    %a.anchor{ href: "#automatic", aria_hidden: "true" }
    Kan ändringsloggar bli automatiskt tolkade?

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

  %p
    #{link_to "Vandamme", vandamme} är en Ruby gem skapad av gruppen
    #{link_to "Gemnasium", gemnasium} som tolkar många (men inte alla)
    ändringsloggar för öppen källkod.

  %h4#yanked
    %a.anchor{ href: "#yanked", aria_hidden: "true" }
    Hur är det med brådskande utgåvor ("yanked")?

  %p
    Brådskande utgåvor är versioner som måste släppas på grund av 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:

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

  %p
    Taggen <code>[YANKED]</code> 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.

  %h4#rewrite
    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
    Borde du någonsin förändra en ändringslogg?

  %p
    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.

  %p
    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.

  %h4#contribute
    %a.anchor{ href: "#contribute", aria_hidden: "true" }
    Hur kan jag bidra?

  %p
    Detta dokument är inte <strong>sanningen</strong>, det är en noga övervägd
    åsikt tillsammans med information och exempel jag har samlat på mig.

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

  %p
    Så tveka inte att <strong>#{link_to "kasta dig in i diskussionen", gh}</strong>.

.press
  %h3 Samtal
  %p
    Jag var med i #{link_to "The Changelog podcast", thechangelog}
    för att prata om varför förvaltare och bidragsgivare bör bry sig om
    ändringsloggar, och motiveringen bakom detta projekt.

{'fraction_non_alphanumeric': 0.07666197934345148, 'fraction_numerical': 0.00644911021674829, 'mean_word_length': 3.309235269536147, 'pattern_counts': {'":': 0, '<': 67, '<?xml version=': 0, '>': 67, 'https://': 12, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7126741', 'n_tokens_mistral': 7889, 'n_tokens_neox': 7667, 'n_words': 2481}