Release notes och changelog

Release notes är den daterade förstahandsdokumentationen av en produktförändring: vad som lanserades, vem det påverkar, vad som fungerar annorlunda och vad en användare måste göra härnäst. En changelog är den kronologiska samlingen av dessa poster. Formatet är ett verktyg för kvarhållande innan det är en trafiktillgång; kunder använder det för att planera arbete och undvika överraskningar.

Den styrande regeln är konsekvens före firande. En release kan vara spännande för teamet, men läsaren behöver först veta om deras arbetsflöde, integration, data, behörigheter, pris eller kompatibilitet har ändrats. Ange den konsekvensen på klarspråk, förklara sedan funktionen. Inom SEO-posttyper -systemet är release notes supportinnehåll i kvarhållandefasen; deras värde kommer från permanenta dokument som aldrig tyst skrivs om.

Frågor det besvarar

En fullständig release-note-post besvarar frågorna som en nuvarande användare ställer efter att ha sett en produktförändring eller stött på okänt beteende:

• Vad ändrades, och på vilket releasedatum eller version ändrades det?
• Är ändringen tillgänglig nu, rullas den ut gradvis, är den i beta, eller begränsad av plan, region, plattform eller kontotyp?
• Vem påverkas, inklusive administratörer, slutanvändare, utvecklare, partners eller en definierad integration?
• Vad var det tidigare beteendet, och vad är annorlunda nu?
• Behöver användaren migrera, uppdatera inställningar, återauktorisera åtkomst, omskola kollegor eller vidta ingen åtgärd?
• Är ändringen brytande, utfasad, reversibel, säkerhetskänslig eller sannolikt att förändra lagrad data?
• Var finns de uppdaterade instruktionerna, den tekniska referensen, kända begränsningar och supportvägen?
• Hur kan en läsare verifiera att det nya beteendet är aktivt på deras konto?

Få inte läsare att gissa effekten utifrån etiketter som “förbättrat”, “uppdaterat” eller “effektiviserat”. “Export är förbättrade” är marknadsföring men inte verifierbart. “CSV-export innehåller nu de tillämpade lands- och modellfiltren i två nya kolumner; befintliga kolumner och ordning är oförändrade” definierar den observerbara förändringen och dess kompatibilitetsgräns.

När denna posttyp ska användas

Använd release notes när en händelse har lanserats eller har ett fast tillgänglighetstillstånd och skapar en användarsynlig skillnad värd att bevara i produkthistoriken. Sökavsikt är vanligtvis navigerande eller informativ: läsare söker efter en produkt plus “release notes”, ett versionsnummer, en ändrad funktion, en utfasad funktion eller en obekant gränssnittsetikett. Använd inte formatet som en löftesbacklog, en allmän nyhetsfeed eller en ersättning för uppgiftsdokumentation.

En ändring behöver inte ett nytt gränssnitt för att kvalificera sig. API-beteende, lagring, beräkningar, autentisering, format, gränser, standardvärden, fakturering och tillgänglighet kan alla kräva en post. En intern omstrukturering utan observerbar konsekvens gör det inte.

Bäst för dessa företagstyper

Rankingen återspeglar behovet av att upprätthålla ett daterat offentligt kontrakt med befintliga användare.

1. SaaS . Den starkaste passformen eftersom kontinuerligt levererade gränssnitt, API:er, behörigheter, integrationer och plangränser kan ändras mellan kundbesök. Poster bör inkludera utrullningsstatus, påverkade planer, administratörspåverkan och dokumentationslänkar.
2. Marknadsplatser . Högt värde eftersom en release kan påverka köpare, säljare, moderatorer, betalningsmottagare eller partners olika. Segmentera effekten och presentera inte en deltagarspecifik ändring som universell.
3. E-handel . Användbart för ändringar i konto, kassa, prenumeration, returer, lojalitet, leverans och säljarverktyg. Separera påverkan på butikskunder från påverkan på operatörer eller integrationer, särskilt kring betalningar och orderstatus.
4. Tillverkare och industriella leverantörer . Viktigt för firmware, styrsystem, uppkopplad utrustning, tekniska portaler och specifikationsrevisioner. Version, modellkompatibilitet, säkerhetsgränser och återställningsmöjlighet måste vara explicita.
5. Finans, fintech och försäkring . Värdefullt men granskningsintensivt eftersom ändringar i beräkningar, behörighet, upplysningar, autentisering och datahantering kan ha regulatoriska konsekvenser. Dokumentera jurisdiktion, godkännande, ikraftträdandedatum och ersatt beteende.
6. B2B-tjänster . Selektivt användbart när tjänsten inkluderar en underhållen plattform, metodik, datamängd, klientportal eller standardleverans. Vanlig företagsnytt hör hemma någon annanstans om den inte ändrar kundkontraktet eller arbetsflödet.

Sökavsikt

Efterfrågan på release notes är ofta lågvolymig och högspecifik. Sökfrågor inkluderar ett produktnamn med “changelog”, “senaste versionen”, “vad ändrades”, “ny instrumentpanel”, en API-version, ett fel som introducerats efter en uppdatering eller ett utfasningsdatum. Den som söker ber inte om en bred produktsäljpitch. De vill ha en auktoritativ tidsstämpel och tillräckligt med detaljer för att fatta ett beslut.

Det användbara resultatets form börjar med produkt + version eller datum + ändring + effekt. Placera dessa fakta i titeln, inledande sammanfattning, rubriker och metadata utan att tvinga varje mindre post till en egen indexerbar URL. Stabila ankare låter supportteam och AI-svar citera en post; dedikerade sidor är motiverade när en release har betydande migreringsarbete, distinkt efterfrågan eller flera relaterade ändringar.

Release notes är en underskattad aktualitetssignal eftersom de exponerar verklig förändring i den takt den sker. Detta berättigar inte att ändra datum för att verka aktiv. Postens datum, aktuell dokumentation, produktbeteende och migrationsvägledning måste överensstämma.

Sidstruktur

Ordintervall anger betoning, inte kvoter. Behåll samma fältordning så att läsare kan skanna både små korrigeringar och brytande releaser.

Gruppera ändringar med stabila etiketter som Tillagt, Ändrat, Fixat, Utfasad, Borttaget, Säkerhet, men låt aldrig en etikett ersätta förklaringen. “Fixat: exporter” är inte en användbar dokumentation. Varje objekt måste namnge det tidigare symptomet eller begränsningen, det nya observerbara tillståndet, påverkad omfattning och eventuell nödvändig åtgärd.

Obligatoriska element

Position är en del av riskkontroll: en migrationsvarning som visas efter funktionsfirandet kommer för sent.

Frontmatter och strukturerad data

Följ frontmatter-specifikationen . Denna spelbokssida använder entity = "post-type-release-notes". En producerad changelog bör använda ett stabilt produkt-och-strömvärde som entity = "atlas-cloud-release-notes"; en enskild release kan använda entity = "atlas-cloud-2026-08". Använd inte en kampanjslogan eller föränderlig releasetitel som identifierare.

Använd schemaType = "Article" för en enskild release-note-sida. Om webbplatsen exponerar ett index som en distinkt entitet kan CollectionPage beskriva det indexet medan varje väsentlig post förblir en synlig daterad post. Lägg till FAQPage endast när FAQ är synlig och stöds av implementationen. Använd inte HowTo enbart för att migrationsinstruktioner innehåller steg, och markera inte en produkt som nyligen lanserad när sidan bara korrigerade formulering.

Lagrera releasedatum separat från publicerings- och ändringsdatum. Rekommenderade fält inkluderar produkt, ström, version, status, releasedAt, plattformar, planer, regioner, påverkade roller, breakingChange, actionRequired, deprecationDate, ägare, kanonisk URL och dokumentationsmål. För en stegvis utrullning, behåll ett releasedatum och ange tidsfönstret i synlig text.

Fullständigt exempel

Det fiktiva exemplet nedan visar en väsentlig release. Det håller migrationskonsekvensen före funktionssammanfattningen och använder en stabil versions-URL.

+++
title = "Atlas Cloud 4.8 Release Notes — 27 augusti 2026"
seoTitle = "Atlas Cloud 4.8 Release Notes: Export API-migrering"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "Atlas release notes", "export API v2", "Atlas changelog", "exportmigrering", "Atlas produktuppdateringar" ]
description = "Atlas Cloud 4.8 lägger till sparade exportvyer och API v2, förklarar deadline för v1-utfasning och ger administratörer en testad migrerings- och valideringsväg."
type = "academy"
date = "2026-08-27 10:00:00"
schemaType = "Article"
product = "Atlas Cloud"
version = "4.8"
releaseStatus = "rolling-out"
releasedAt = "2026-08-27"
platforms = [ "web", "API" ]
affectedRoles = [ "arbetsyta-administratör", "integrationsägare" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Atlas Cloud 4.8 release notes

Atlas Cloud 4.8 började rullas ut den 27 augusti 2026. Det lägger till sparade exportvyer och Export API v2. Arbetsytemedlemmar kan använda sparade vyer utan att ändra befintliga exporter. Integrationsägare som använder API v1 måste migrera före den 15 oktober 2026; efter det datumet kommer v1-exportförfrågningar att returnera ett osupportat versionssvar.

## Åtgärd krävs: migrera Export API v1

**Vem påverkas:** integrationer som skickar förfrågningar till `/api/v1/exports`. Dashboard-exporter och API v2-klienter påverkas inte.

**Vad ändras:** v2 kräver ett explicit `format`-värde och returnerar exportjobbidentifieraren i `data.id`. Filkolumnerna ändras inte om inte en sparad vy väljer en annan fältuppsättning.

**Deadline:** slutför migrering och validering före den 15 oktober 2026. Befintliga v1-förfrågningar fortsätter att fungera fram till dess.

1. Skapa en testförfrågan mot v2-slutpunkten med samma filter som en nuvarande v1-förfrågan.
2. Lägg till det obligatoriska `format`-värdet och läs jobbidentifieraren från `data.id`.
3. Jämför radantal, fältuppsättning, tidszon och en känd post mellan den gamla och nya filen.
4. Uppdatera produktion först efter att jämförelsen är godkänd. Behåll den tidigare konfigurationen tillgänglig tills den första schemalagda produktionsexporten lyckas.

Om testet inte matchar, lämna produktionsintegrationen på v1 och skicka till support det sanitiserade förfrågnings-ID:t, tidsstämpeln, tidszonen och fältavvikelsen. Inkludera inte en åtkomsttoken.

## Tillagt: sparade exportvyer

Arbetsyteadministratörer kan spara en namngiven uppsättning fält, filter, sortering och filformat. Medlemmar med exportbehörighet kan återanvända vyn; att spara en vy ger inte åtkomst till poster de inte redan kunde se.

För att verifiera tillgänglighet, öppna **Exporter → Vyer** och leta efter **Spara aktuell vy**. Kontrollen kan ta upp till tre dagar att visas under utrullningen. Den ingår i Standard- och Enterprise-planer i alla regioner.

## Fixat: landsfilksetiketter i CSV-filer

CSV-exporter använder nu det synliga landsnamnet i filtersammanfattningskolumnen istället för det interna tvåbokstavsvärdet. Detta ändrar endast sammanfattningsetiketten; filtrerade poster och befintliga datakolumner är oförändrade.

## Kända begränsningar

Sparade vyer kan ännu inte överföras mellan arbetsytor. Ett borttaget fält tas bort från vyn nästa gång den körs, och exporthistoriken registrerar den uteslutningen.

## Uppdaterade resurser

- Export API v2 migrationsguide
- Export API-referens
- Dokumentation om exportbehörigheter
- Felsökning av export

Exemplet namnger en testad kompatibilitetsgräns, skiljer utrullning från releasedatum och ger läsare ett sätt att verifiera åtkomst.

Designgalleri

Behåll samma releasefakta i varje layoutvariant så att designgranskning testar hierarki, inte olika redaktionella beslut.

Kvalitetschecklista

En release note är redo först när vartenda tillämpligt påstående är sant:

• Titeln och inledningen identifierar produkten, datumet eller versionen, den huvudsakliga ändringen och den påverkade målgruppen.
• Tillgänglighet är precis: lanserad, utrullning pågår med tidsfönster, beta, opt-in, planbegränsad, regionbegränsad, uppskjuten eller återkallad.
• Varje post förklarar observerbart före-och-efter-beteende istället för att förlita sig på “förbättrat”, “förstärkt” eller “fixat”.
• Etiketterna Tillagt, Ändrat, Fixat, Utfasad, Borttaget och Säkerhet tillämpas konsekvent.
• Brytande ändringar visas före marknadsföringsfördelar och anger den påverkade omfattningen, deadline, felfallet, ersättning, migrering, validering, återställning eller supportväg.
• Datum skiljer på release, publicering, väsentlig ändring, utfasning och borttagning.
• Versionsidentifierare, slutpunktsnamn, menyetiketter, planer, regioner och plattformsomfattning har verifierats mot det lanserade tillståndet.
• Läsaren kan avgöra om åtgärd krävs och hur slutförande bekräftas.
• Aktuell dokumentation återspeglar det nya beteendet och länkar tillbaka till relevant release där historik är viktig.
• Skärmbilder har ett inspelningsdatum eller en version och en textmotsvarighet för kontrollerna eller tillstånden de visar.
• Arkivet tillhandahåller stabila URL:er eller ankare, nyast-först-bläddring och ett sätt att nå äldre poster.
• FAQ-svar i frontmatter och synliga FAQ-svar matchar exakt, och analys skiljer bläddring från migrering eller produktåtgärd.

Vanliga misstag

Att skriva kampanjtext istället för en dokumentation. “Vi är så glada över att förändra ditt arbetsflöde” försenar faktumet. Led med det lanserade beteendet, målgruppen, tillgängligheten och åtgärden; lägg berättelsen i ett separat lanseringstillkännagivande.

Att begrava brytande ändringar. En migrationsdeadline under skärmbilder och fördelar skapar undvikbart misslyckande. Sätt varningen först och gör den självständigt begriplig.

Att kalla en utrullning för en lansering överallt. Om endast vissa konton har åtkomst, säg utrullning och ange det förväntade tidsfönstret. Användare förlorar förtroende när instruktioner beskriver en kontroll de ännu inte kan se.

Att använda “buggfixar och förbättringar”. Detta döljer påverkat beteende och hindrar användare från att känna igen att deras problem löstes. Namnge symptomet, omfattningen och det nya tillståndet om inte säkerhetsavslöjande kräver återhållsamhet.

Att ändra datum för aktualitet. En stavfelkorrigering gör inte en gammal release ny. Bevara releasedAt, dokumentera en väsentlig korrigering separat och använd lastmod endast när den synliga dokumentationen ändrades på ett meningsfullt sätt.

Att duplicera aktuella instruktioner. En lång installationsprocedur kommer att driva isär på två ställen. Sammanfatta det ändrade steget i release-noten och låt underhållen dokumentation äga det fullständiga aktuella arbetsflödet.

Intern länkning

Bra intern länkning gör changeloggen till det historiska lagret av produktkunskap. Länka från aktuell dokumentation när en övergång förklarar ändrat beteende. Länka från releasen till exakt dokumentation, migrering, felsökning, policy eller kompatibilitetsvägledning där användaren behöver det.

Använd en kanonisk dokumentation för varje väsentlig ändring. Ett lanseringsinlägg, en funktionssida eller ett supportsvar kan citera den; ingen bör kopiera den. Arkivnavigering bör koppla samman angränsande releaser och indexet. För utfasningar, länka den gamla posten till dess ersättning och migrationsvägledningen tillbaka till meddelandet.

Hur man mäter resultat

Mät om användare upptäcker rätt dokumentation, förstår effekten, slutför nödvändig åtgärd och behöver mindre förtydligande. Råa sidvisningar är inte målet: en liten fix kan tjäna sitt syfte med lite trafik.

Använd promptspårning för produkt-plus-version-frågor, ändrade funktionsnamn, utfasningsdatum och “senaste uppdatering”-formuleringar. Använd käll- och citatintelligens för att inspektera om AI-svar citerar den kanoniska posten och bevarar tillgänglighet, påverkad omfattning, deadline och nödvändig åtgärd. AmICited Cockpit kan placera release-relaterad synlighet och citerade URL:er bredvid organisk landningsaktivitet och utvalda produkthändelser.

Före publicering, dokumentera den påverkade målgruppen, utrullningsfönstret, supportvolymen, migrationsbaslinjen, målfrågor och prompts samt händelsen som bevisar framgång. Granska:

• visningar och besök för produkt-, versions-, funktions-, utfasnings- och changelog-frågor;
• AI-citat som återger korrekt releasedatum, status, kompatibilitetsgräns och åtgärd;
• postnivå-ankare eller sidvisningar snarare enbart changelog-indexvisningar;
• klick in i uppdaterad dokumentation, migrering, felsökning eller verifieringsvägar;
• migrationsstarter, valideringsslutföranden och kvarvarande äldre användning där integritetssäker telemetri finns;
• supportkontakter orsakade av otydlig omfattning, saknad utrullningsåtkomst eller odokumenterat beteende;
• föråldrade svar efter en korrigering, återkallelse, ersättande release eller deadlinedeadlineändring.

Följ hur vi mäter resultat för att separera upptäckt, citat, engagemang, uppgiftsslutförande, kvarhållande och affärsresultat. Annotera lanseringar, incidenter, kampanjer och obligatoriska migreringar innan du tolkar förändringar. En trafiktopp kan indikera förvirring, och ett citerat svar är skadligt om det utelämnar deadline för brytande ändringar.

FAQ

Vanliga frågor