Versjonsnotater og endringslogg

Versjonsnotater er den daterte førstepartsoversikten over en produktendring: hva som ble lansert, hvem det påvirker, hva som fungerer annerledes, og hva en bruker må gjøre videre. En endringslogg er den kronologiske samlingen av disse oppføringene. Formatet er et verktøy for kundebevaring før det er en trafikkressurs; kunder bruker det til å planlegge arbeid og unngå overraskelser.

Hovedregelen er konsekvens før feiring. En utgivelse kan være spennende for teamet, men leseren må først vite om arbeidsflyten, integrasjonen, dataene, tillatelsene, prisen eller kompatibiliteten deres har endret seg. Angi denne konsekvensen i klarspråk, og forklar deretter kapabiliteten. Innen SEO-innholdstyper -systemet er versjonsnotater støtteinnhold på bevaringsstadiet; verdien kommer fra permanente poster som aldri skrives om i stillhet.

Spørsmålene den besvarer

En komplett versjonsnotatoppføring svarer på spørsmålene en eksisterende bruker stiller etter å ha sett en produktendring eller støtt på ukjent atferd:

• Hva endret seg, og på hvilken utgivelsesdato eller versjon skjedde endringen?
• Er endringen tilgjengelig nå, rulles den ut gradvis, er den i beta, eller er den begrenset av abonnement, region, plattform eller kontotype?
• Hvem berøres, inkludert administratorer, sluttbrukere, utviklere, partnere eller en definert integrasjon?
• Hva var den tidligere atferden, og hva er annerledes nå?
• Må brukeren migrere, oppdatere innstillinger, autorisere tilgang på nytt, omskolere kolleger eller ikke gjøre noe?
• Er endringen brytende, avskrevet, reversibel, sikkerhetsrelatert eller sannsynlig å endre lagrede data?
• Hvor finnes oppdaterte instruksjoner, teknisk referanse, kjente begrensninger og støttevei?
• Hvordan kan en leser bekrefte at den nye atferden er aktiv på kontoen deres?

Ikke få lesere til å slutte seg til konsekvenser fra etiketter som «forbedret», «oppdatert» eller «strømlinjeformet». «Eksporter er forbedret» er reklamepreget, men ikke verifiserbart. «CSV-eksporter inkluderer nå de anvendte land- og modellfiltrene i to nye kolonner; eksisterende kolonner og rekkefølge er uendret» definerer den observerbare endringen og kompatibilitetsgrensen.

Når du skal bruke denne innholdstypen

Bruk versjonsnotater når en hendelse er lansert eller har en fast tilgjengelighetsstatus og skaper en brukersynlig forskjell verdt å bevare i produkthistorikken. Søkeintensjon er vanligvis navigasjonsbasert eller informasjonsbasert: lesere søker på et produkt pluss «versjonsnotater», et versjonsnummer, en endret funksjon, en avskrivning eller en ukjent grensesnittetikett. Ikke bruk formatet som en løftesbeholdning, en generell kunngjøringsfeed eller en erstatning for oppgavedokumentasjon.

En endring trenger ikke et nytt grensesnitt for å kvalifisere. API-atferd, oppbevaring, beregninger, autentisering, formater, grenser, standardverdier, fakturering og tilgjengelighet kan alle kreve en oppføring. En intern omstrukturering uten observerbar konsekvens gjør ikke det.

Best for disse forretningstypene

Rangeringen gjenspeiler behovet for å opprettholde en datert offentlig kontrakt med eksisterende brukere.

1. SaaS . Den sterkeste passformen fordi kontinuerlig leverte grensesnitt, API-er, tillatelser, integrasjoner og abonnementsgrenser kan endres mellom kundebesøk. Oppføringer bør inkludere utrullingsstatus, berørte abonnementer, administratorpåvirkning og dokumentasjonslenker.
2. Markedsplasser . Høy verdi fordi én utgivelse kan påvirke kjøpere, selgere, moderatorer, betalingsmottakere eller partnere forskjellig. Segmenter påvirkningen og unngå å presentere en deltakerspesifikk endring som universell.
3. E-handel . Nyttig for endringer i konto, betaling, abonnement, returer, lojalitet, levering og selgerverktøy. Skill mellom påvirkning på nettbutikkkunder og på operatører eller integrasjoner, spesielt rundt betalinger og ordrestatuser.
4. Produsenter og industrileverandører . Viktig for fastvare, kontrollprogramvare, tilkoblet utstyr, tekniske portaler og spesifikasjonsrevisjoner. Versjon, modellkompatibilitet, sikkerhetsgrenser og tilgjengelighet for tilbakrulling må være tydelige.
5. Finans, fintech og forsikring . Verdifullt, men gjennomgangskrevende fordi endringer i beregninger, kvalifisering, opplysningsplikt, autentisering og datahåndtering kan ha regulatoriske konsekvenser. Registrer jurisdiksjon, godkjenning, ikrafttredelsesdato og tidligere atferd.
6. B2B-tjenester . Selektivt nyttig når tjenesten inkluderer en vedlikeholdt plattform, metode, datasett, klientportal eller standardleveranse. Vanlige selskapsnyheter hører hjemme andre steder med mindre de endrer kundekontrakten eller arbeidsflyten.

Søkeintensjon

Etterspørselen etter versjonsnotater er ofte lavt volum og høy spesifisitet. Søk inkluderer et produktnavn med «endringslogg», «siste versjon», «hva endret seg», «nytt dashbord», en API-versjon, en feil introdusert etter en oppdatering, eller en avskrivningsdato. Søkeren spør ikke etter en bred produkthets. De vil ha et autoritativt tidsstempel og nok detaljer til å ta en beslutning.

Den nyttige resultatformen begynner med produkt + versjon eller dato + endring + konsekvens. Plasser disse faktaene i tittelen, innledende sammendrag, overskrifter og metadata uten å tvinge hver mindre oppføring til sin egen indekserbare URL. Stabile anker lar støtteteam og AI-svar sitere én oppføring; dedikerte sider er berettiget når en utgivelse har betydelig migreringsarbeid, særegen etterspørsel eller flere relaterte endringer.

Versjonsnotater er et undervurdert aktualitetssignal fordi de avslører reell endring i det tempoet den skjer. Dette rettferdiggjør ikke å endre datoer for å fremstå aktiv. Oppføringsdatoen, gjeldende dokumentasjon, produktatferd og migreringsveiledning må samsvare.

Sidestruktur

Ordbånd setter vekt, ikke kvoter. Behold samme feltrekkefølge slik at lesere kan skanne små rettelser og brytende utgivelser på samme måte.

Grupper endringer med stabile etiketter som Lagt til, Endret, Rettet, Avskrevet, Fjernet, Sikkerhet, men la aldri en etikett erstatte forklaringen. «Rettet: eksporter» er ikke en nyttig post. Hvert element må navngi det tidligere symptomet eller begrensningen, den nye observerbare tilstanden, berørt omfang og eventuell nødvendig handling.

Nødvendige elementer

Plassering er en del av risikokontroll: en migreringsadvarsel som vises etter funksjonsfeiringen kommer for sent.

Frontmatter og strukturert data

Følg frontmatter-spesifikasjonen . Denne spillebok-siden bruker entity = "post-type-release-notes". En produsert endringslogg bør bruke en stabil produkt-og-strøm-verdi som entity = "atlas-cloud-release-notes"; en individuell utgivelse kan bruke entity = "atlas-cloud-2026-08". Ikke bruk et kampanjeslagord eller endringsbar utgivelsestittel som identifikator.

Bruk schemaType = "Article" for en individuell versjonsnotatside. Hvis nettstedet viser en indeks som en distinkt enhet, kan CollectionPage beskrive den indeksen mens hver materielle oppføring forblir et synlig datert element. Legg til FAQPage bare når FAQ-en er synlig og støttet av implementeringen. Ikke bruk HowTo bare fordi migreringsinstruksjoner inneholder trinn, og ikke marker et produkt som nylig lansert når siden bare korrigerte ordlyd.

Lagre utgivelsesdato separat fra publiserings- og endringsdatoer. Anbefalte felt inkluderer produkt, strøm, versjon, status, releasedAt, plattformer, abonnementer, regioner, berørte roller, breakingChange, actionRequired, deprecationDate, eier, kanonisk URL og dokumentasjonsmål. For en gradvis utrulling, behold én utgivelsesdato og oppgi vinduet i synlig tekst.

Fullstendig eksempel

Det fiktive eksemplet nedenfor viser én vesentlig utgivelse. Det holder migreringskonsekvensen foran funksjonssammendraget og bruker en stabil versjons-URL.

+++
title = "Atlas Cloud 4.8 Release Notes — 27 August 2026"
seoTitle = "Atlas Cloud 4.8 Release Notes: Export API Migration"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "Atlas release notes", "export API v2", "Atlas changelog", "export migration", "Atlas product updates" ]
description = "Atlas Cloud 4.8 adds saved export views and API v2, explains the v1 deprecation deadline, and gives administrators a tested migration and validation path."
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 = [ "workspace administrator", "integration owner" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Versjonsnotater for Atlas Cloud 4.8

Atlas Cloud 4.8 begynte å rulles ut 27. august 2026. Det legger til lagrede eksportvisninger og Export API v2. Arbeidsområdemedlemmer kan bruke lagrede visninger uten å endre eksisterende eksporter. Integrasjonseiere som bruker API v1, må migrere før 15. oktober 2026; etter den datoen vil v1-eksportforespørsler returnere et ikke-støttet-versjon-svar.

## Handling kreves: migrer Export API v1

**Hvem berøres:** integrasjoner som sender forespørsler til `/api/v1/exports`. Dashbordeksporter og API v2-klienter berøres ikke.

**Hva endres:** v2 krever en eksplisitt `format`-verdi og returnerer eksportjobbidentifikatoren i `data.id`. Filkolonnene endres ikke med mindre en lagret visning velger et annet feltsett.

**Frist:** fullfør migrering og validering før 15. oktober 2026. Eksisterende v1-forespørsler fortsetter å fungere frem til da.

1. Opprett en testforespørsel mot v2-endepunktet med samme filtre som en gjeldende v1-forespørsel.
2. Legg til den påkrevde `format`-verdien og les jobbidentifikatoren fra `data.id`.
3. Sammenlign radantall, feltsett, tidssone og en kjent post mellom de gamle og nye filene.
4. Oppdater produksjonen først etter at sammenligningen er vellykket. Hold den forrige konfigurasjonen tilgjengelig til den første planlagte produksjonseksporten lykkes.

Hvis testen ikke samsvarer, la produksjonsintegrasjonen være på v1 og send støtte den anonymiserte forespørsels-ID-en, tidsstempel, tidssone og feltavvik. Ikke inkluder et tilgangstoken.

## Lagt til: lagrede eksportvisninger

Arbeidsområdeadministratorer kan lagre et navngitt sett med felt, filtre, sortering og filformat. Medlemmer med eksporttillatelse kan gjenbruke visningen; lagring av en visning gir ikke tilgang til poster de ikke allerede kunne se.

For å bekrefte tilgjengelighet, åpne **Eksporter → Visninger** og se etter **Lagre gjeldende visning**. Kontrollen kan ta opptil tre dager å vises under utrulling. Den er inkludert i Standard- og Enterprise-abonnementer i alle regioner.

## Rettet: landfilteretiketter i CSV-filer

CSV-eksporter bruker nå det synlige landnavnet i filteroppsummeringskolonnen i stedet for den interne to-bokstavsverdien. Dette endrer bare oppsummeringsetiketten; filtrerte poster og eksisterende datakolonner er uendret.

## Kjente begrensninger

Lagrede visninger kan ennå ikke overføres mellom arbeidsområder. Et slettet felt fjernes fra visningen neste gang den kjøres, og eksporthistorikken registrerer utelatelsen.

## Oppdaterte ressurser

- Migreringsveiledning for Export API v2
- Export API-referanse
- Dokumentasjon for eksporttillatelser
- Feilsøking for eksport

Eksemplet navngir en testet kompatibilitetsgrense, skiller utrulling fra utgivelsesdato og gir leserne en måte å bekrefte tilgang på.

Designgalleri

Behold de samme utgivelsesfaktaene i hvert layout-variant slik at designgjennomgang tester hierarki, ikke ulike redaksjonelle beslutninger.

Kvalitetssjekkliste

Et versjonsnotat er klart bare når alle gjeldende påstander er sanne:

• Tittelen og innledningen identifiserer produktet, datoen eller versjonen, den viktigste endringen og berørt målgruppe.
• Tilgjengelighet er presis: lansert, under utrulling med et vindu, beta, valgfri, abonnementsbegrenset, regionsbegrenset, utsatt eller trukket tilbake.
• Hver oppføring forklarer observerbar før-og-etter-atferd i stedet for å stole på «forbedret», «forbedret» eller «rettet».
• Etiketter for lagt til, endret, rettet, avskrevet, fjernet og sikkerhet brukes konsekvent.
• Brytende endringer vises før reklamefordeler og angir berørt omfang, frist, feilmodus, erstatning, migrering, validering, tilbakrullings- eller støttevei.
• Datoer skiller mellom utgivelse, publisering, materiell endring, avskrivning og fjerning.
• Versjonsidentifikatorer, endepunktnavn, menyetiketter, abonnementer, regioner og plattformomfang er verifisert mot lansert tilstand.
• Leseren kan se om handling kreves og hvordan man bekrefter fullføring.
• Gjeldende dokumentasjon gjenspeiler den nye atferden og lenker tilbake til relevant utgivelse der historikk betyr noe.
• Skjermbilder har en innfangingsdato eller -versjon og en tekstevivalent for kontrollene eller tilstandene de viser.
• Arkivet tilbyr stabile URL-er eller anker, nyeste-først-navigering og en måte å nå eldre oppføringer på.
• Frontmatter FAQ-svar og synlige FAQ-svar samsvarer nøyaktig, og analyse skiller mellom navigering og migrering eller produktbruk.

Vanlige feil

Å skrive kampanjetekst i stedet for en post. «Vi er henrykte over å transformere arbeidsflyten din» forsinker fakta. Led med lansert atferd, målgruppe, tilgjengelighet og handling; legg fortellingen i en separat lanseringskunngjøring.

Å begrave brytende endringer. En migreringsfrist under skjermbilder og fordeler skaper unngåelige feil. Sett advarselen først og gjør den forståelig uavhengig.

Å kalle en utrulling for en lansering overalt. Hvis bare noen kontoer har tilgang, si utrulling og oppgi forventet tidsvindu. Brukere mister tillit når instruksjoner beskriver en kontroll de ennå ikke kan se.

Å bruke «feilrettinger og forbedringer». Dette skjuler berørt atferd og hindrer brukere i å gjenkjenne at problemet deres er løst. Navngi symptomet, omfanget og den nye tilstanden med mindre sikkerhetsavsløring krever tilbakeholdenhet.

Å flytte datoer for aktualitet. En skrivefeilretting gjør ikke en gammel utgivelse ny. Bevar releasedAt, registrer en materiell korreksjon separat, og bruk lastmod bare når den synlige posten endret seg meningsfullt.

Å duplisere gjeldende instruksjoner. En lang oppsettsprosedyre vil avvike på to steder. Oppsummer det endrede trinnet i versjonsnotatet og la vedlikeholdt dokumentasjon eie hele den gjeldende arbeidsflyten.

Intern lenking

God intern lenking gjør endringsloggen til det historiske laget av produktkunnskap. Lenk fra gjeldende dokumentasjon når en overgang forklarer endret atferd. Lenk fra utgivelsen til nøyaktig dokumentasjon, migrering, feilsøking, policy eller kompatibilitetsveiledning der brukeren trenger det.

Bruk én kanonisk post for hver materielle endring. En lanseringsartikkel, funksjonsside eller støttesvar kan sitere den; ingen bør kopiere den. Arkivnavigasjon bør koble tilstøtende utgivelser og indeksen. For avskrivninger, lenk den gamle oppføringen til erstatningen og migreringsveiledningen tilbake til varselet.

Hvordan måle resultater

Mål om brukere oppdager riktig post, forstår konsekvensen, fullfører nødvendig handling og trenger mindre avklaring. Rå sidevisninger er ikke målet: en liten rettelse kan tjene sitt formål med lite trafikk.

Bruk sporingsvarsling for produkt-pluss-versjon-spørsmål, endrede funksjonsnavn, avskrivningsdatoer og «siste oppdatering»-ordlyd. Bruk kilde- og siteringsinnsikt for å inspisere om AI-svar siterer den kanoniske oppføringen og bevarer tilgjengelighet, berørt omfang, frist og nødvendig handling. AmICited Cockpit kan plassere utgivelsesrelatert synlighet og siterte URL-er ved siden av organisk landingsaktivitet og utvalgte produkthendelser.

Før publisering, registrer berørt målgruppe, utrullingsvindu, støttevolum, migreringsgrunnlinje, målrettede søk og spørsmål, og hendelsen som beviser suksess. Gjennomgå:

• visninger og besøk for produkt-, versjons-, funksjons-, avskrivnings- og endringsloggsøk;
• AI-siteringer som gjengir korrekt utgivelsesdato, status, kompatibilitetsgrense og handling;
• oppføringsnivå anker- eller sidevisninger i stedet for bare endringsloggindeksvisninger;
• klikk inn i oppdatert dokumentasjon, migrering, feilsøking eller verifiseringsveier;
• migreringsstarter, fullførte valideringer og gjenværende eldre bruk der personvernsikker telemetri finnes;
• støttehenvendelser forårsaket av uklart omfang, manglende utrullingstilgang eller udokumentert atferd;
• utdaterte svar etter en korreksjon, tilbaketrekking, overstyrende utgivelse eller fristendring.

Følg hvordan vi måler resultater for å skille oppdagelse, sitering, engasjement, oppgavefullføring, kundebevaring og forretningsresultater. Annoter lanseringer, hendelser, kampanjer og obligatoriske migreringer før du tolker bevegelse. En økning i trafikk kan indikere forvirring, og et sitert svar er skadelig hvis det utelater fristen for brytende endring.

FAQ

Ofte stilte spørsmål