Notatki wydania i dziennik zmian

Notatki wydania to datowany, własny zapis zmiany produktu: co zostało wydane, kogo dotyczy, co zachowuje się inaczej i co użytkownik musi zrobić dalej. Dziennik zmian to chronologiczny zbiór tych wpisów. Format ten jest narzędziem retencji, zanim stanie się aktywem ruchu; klienci używają go do planowania pracy i unikania niespodzianek.

Naczelną zasadą jest konsekwencja przed celebracją. Wydanie może być ekscytujące dla zespołu, ale czytelnik musi najpierw wiedzieć, czy zmienił się jego przepływ pracy, integracja, dane, uprawnienia, cena lub kompatybilność. Przedstaw tę konsekwencję prostym językiem, a następnie wyjaśnij możliwość. W ramach systemu typów wpisów SEO notatki wydania to treści wsparcia na etapie retencji; ich wartość pochodzi z trwałych zapisów, które nigdy nie są po cichu przepisywane.

Pytania, na które odpowiada

Kompletny wpis notatki wydania odpowiada na pytania, jakie zadaje bieżący użytkownik po zobaczeniu zmiany produktu lub napotkaniu nieznanego zachowania:

• Co się zmieniło i w którym dniu wydania lub wersji?
• Czy zmiana jest dostępna teraz, wprowadzana stopniowo, w fazie beta, czy ograniczona planem, regionem, platformą lub typem konta?
• Kogo dotyczy, w tym administratorów, użytkowników końcowych, programistów, partnerów lub określoną integrację?
• Jakie było poprzednie zachowanie, a co jest inne teraz?
• Czy użytkownik musi migrować, aktualizować ustawienia, ponownie autoryzować dostęp, przeszkolić współpracowników, czy nie podejmować żadnych działań?
• Czy zmiana jest przełomowa, wycofana, odwracalna, wrażliwa pod względem bezpieczeństwa lub może zmienić przechowywane dane?
• Gdzie znajdują się zaktualizowane instrukcje, dokumentacja techniczna, znane ograniczenia i ścieżka wsparcia?
• Jak czytelnik może zweryfikować, że nowe zachowanie jest aktywne na jego koncie?

Nie każ czytelnikom wnioskować o wpływie z etykiet takich jak „ulepszone”, „zaktualizowane” czy „usprawnione”. „Eksporty zostały ulepszone” jest promocyjne, ale nieweryfikowalne. „Eksporty CSV zawierają teraz zastosowane filtry kraju i modelu w dwóch nowych kolumnach; istniejące kolumny i kolejność pozostają niezmienione” definiuje obserwowalną zmianę i jej granicę kompatybilności.

Kiedy używać tego typu wpisu

Używaj notatek wydania, gdy zdarzenie zostało wydane lub ma określony status dostępności i tworzy widoczną dla użytkownika różnicę wartą zachowania w historii produktu. Intencja wyszukiwania jest zazwyczaj nawigacyjna lub informacyjna: czytelnicy szukają nazwy produktu plus „notatki wydania”, numeru wersji, zmienionej funkcji, wycofania lub nieznanej etykiety interfejsu. Nie używaj tego formatu jako backlogu obietnic, ogólnego kanału ogłoszeń ani zamiennika dokumentacji zadań.

Zmiana nie potrzebuje nowego interfejsu, aby się kwalifikować. Zachowanie API, przechowywanie, obliczenia, uwierzytelnianie, formaty, limity, wartości domyślne, rozliczenia i dostępność — wszystko to może wymagać wpisu. Wewnętrzna refaktoryzacja bez obserwowalnych konsekwencji — nie.

Najlepsze dla tych typów biznesowych

Ranking odzwierciedla potrzebę utrzymania datowanej publicznej umowy z istniejącymi użytkownikami.

1. SaaS . Najlepsze dopasowanie, ponieważ stale dostarczane interfejsy, API, uprawnienia, integracje i limity planów mogą zmieniać się między wizytami klientów. Wpisy powinny obejmować stan wdrożenia, dotknięte plany, wpływ na administratorów i linki do dokumentacji.
2. Marketplace . Wysoka wartość, ponieważ jedno wydanie może inaczej wpłynąć na kupujących, sprzedających, moderatorów, odbiorców wypłat lub partnerów. Segmentuj wpływ i nie przedstawiaj zmiany specyficznej dla uczestnika jako uniwersalnej.
3. E-commerce . Przydatne w przypadku zmian konta, kasy, subskrypcji, zwrotów, lojalności, dostawy i narzędzi sprzedawcy. Oddziel wpływ na klientów sklepu od wpływu na operatorów lub integracje, szczególnie w obszarze płatności i stanów zamówień.
4. Producenci i dostawcy przemysłowi . Ważne dla zmian oprogramowania sprzętowego, oprogramowania sterującego, podłączonego sprzętu, portali technicznych i rewizji specyfikacji. Wersja, kompatybilność modeli, granice bezpieczeństwa i dostępność wycofania muszą być jednoznaczne.
5. Finanse, fintech i ubezpieczenia . Cenne, ale wymagające intensywnego przeglądu, ponieważ zmiany obliczeń, kwalifikowalności, ujawnień, uwierzytelniania i przetwarzania danych mogą mieć konsekwencje regulacyjne. Rejestruj jurysdykcję, zatwierdzenie, datę wejścia w życie i zastąpione zachowanie.
6. Usługi B2B . Selektywnie przydatne, gdy usługa obejmuje utrzymywaną platformę, metodologię, zestaw danych, portal klienta lub standardowy produkt. Zwykłe wiadomości firmowe należą gdzie indziej, chyba że zmieniają umowę z klientem lub przepływ pracy.

Intencja wyszukiwania

Popyt na notatki wydania jest często niskiego wolumenu i wysokiej szczegółowości. Zapytania obejmują nazwę produktu z „dziennik zmian”, „najnowsza wersja”, „co się zmieniło”, „nowy panel”, wersję API, błąd wprowadzony po aktualizacji lub datę wycofania. Osoba wyszukująca nie prosi o ogólną prezentację produktu. Chce autorytatywnego znacznika czasu i wystarczająco dużo szczegółów, aby podjąć decyzję.

Przydatny kształt wyniku zaczyna się od produkt + wersja lub data + zmiana + wpływ. Umieść te fakty w tytule, początkowym podsumowaniu, nagłówkach i metadanych, nie zmuszając każdego drobnego wpisu do własnego indeksowalnego adresu URL. Stabilne kotwice pozwalają zespołom wsparcia i odpowiedziom AI cytować jeden wpis; dedykowane strony są uzasadnione, gdy wydanie ma znaczną pracę migracyjną, wyraźny popyt lub kilka powiązanych zmian.

Notatki wydania są niedocenianym sygnałem aktualności, ponieważ ujawniają prawdziwe zmiany w tempie, w jakim występują. Nie usprawiedliwia to zmieniania dat, aby wyglądać na aktywne. Data wpisu, bieżąca dokumentacja, zachowanie produktu i wskazówki migracyjne muszą być zgodne.

Struktura strony

Zakresy słowne wyznaczają nacisk, a nie limity. Zachowaj tę samą kolejność pól, aby czytelnicy mogli skanować zarówno drobne poprawki, jak i przełomowe wydania.

Grupuj zmiany za pomocą stabilnych etykiet, takich jak Dodano, Zmieniono, Naprawiono, Wycofano, Usunięto, Bezpieczeństwo, ale nigdy nie pozwól, aby etykieta zastąpiła wyjaśnienie. „Naprawiono: eksporty” nie jest użytecznym zapisem. Każda pozycja musi określać poprzedni objaw lub ograniczenie, nowy obserwowalny stan, dotknięty zakres i wszelkie wymagane działanie.

Wymagane elementy

Pozycja jest częścią kontroli ryzyka: ostrzeżenie o migracji pokazane po celebracji funkcji pojawia się zbyt późno.

Frontmatter i dane strukturalne

Postępuj zgodnie ze specyfikacją frontmatter . Ta strona playbooka używa entity = "post-type-release-notes". Wyprodukowany dziennik zmian powinien używać stabilnej wartości produktu i strumienia, takiej jak entity = "atlas-cloud-release-notes"; pojedyncze wydanie może używać entity = "atlas-cloud-2026-08". Nie używaj sloganu kampanii ani zmiennego tytułu wydania jako identyfikatora.

Użyj schemaType = "Article" dla pojedynczej strony notatki wydania. Jeśli witryna udostępnia indeks jako odrębny byt, CollectionPage może opisywać ten indeks, podczas gdy każdy istotny wpis pozostaje widoczną datowaną pozycją. Dodaj FAQPage tylko wtedy, gdy FAQ jest widoczne i obsługiwane przez implementację. Nie używaj HowTo tylko dlatego, że instrukcje migracji zawierają kroki, i nie oznaczaj produktu jako nowo wydanego, gdy strona tylko poprawiła sformułowania.

Przechowuj datę wydania oddzielnie od dat publikacji i modyfikacji. Zalecane pola obejmują: produkt, strumień, wersję, status, releasedAt, platformy, plany, regiony, dotknięte role, breakingChange, actionRequired, deprecationDate, właściciela, kanoniczny URL i cele dokumentacji. W przypadku stopniowego wdrażania zachowaj jedną datę wydania i podaj okno w widocznym tekście.

Pełny przykład

Poniższy fikcyjny przykład przedstawia jedno istotne wydanie. Utrzymuje konsekwencje migracji przed podsumowaniem funkcji i używa stabilnego URL wersji.

+++
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"
+++

# Atlas Cloud 4.8 release notes

Atlas Cloud 4.8 began rolling out on 27 August 2026. It adds saved export views and Export API v2. Workspace members can use saved views without changing existing exports. Integration owners using API v1 must migrate before 15 October 2026; after that date, v1 export requests will return an unsupported-version response.

## Action required: migrate Export API v1

**Who is affected:** integrations that send requests to `/api/v1/exports`. Dashboard exports and API v2 clients are not affected.

**What changes:** v2 requires an explicit `format` value and returns the export job identifier in `data.id`. The file columns do not change unless a saved view selects a different field set.

**Deadline:** complete migration and validation before 15 October 2026. Existing v1 requests continue to work until then.

1. Create a test request against the v2 endpoint with the same filters as a current v1 request.
2. Add the required `format` value and read the job identifier from `data.id`.
3. Compare row count, field set, timezone, and a known record between the old and new files.
4. Update production only after the comparison passes. Keep the previous configuration available until the first scheduled production export succeeds.

If the test does not match, leave the production integration on v1 and send support the sanitized request ID, timestamp, timezone, and field mismatch. Do not include an access token.

## Added: saved export views

Workspace administrators can save a named set of fields, filters, sorting, and file format. Members with export permission can reuse the view; saving a view does not grant access to records they could not already see.

To verify availability, open **Exports → Views** and look for **Save current view**. The control may take up to three days to appear during rollout. It is included on Standard and Enterprise plans in all regions.

## Fixed: country filter labels in CSV files

CSV exports now use the visible country name in the filter-summary column instead of the internal two-letter value. This changes the summary label only; filtered records and existing data columns are unchanged.

## Known limitations

Saved views cannot yet be transferred between workspaces. A deleted field is removed from the view the next time it runs, and the export history records that omission.

## Updated resources

- Export API v2 migration guide
- Export API reference
- Export permissions documentation
- Export troubleshooting

Przykład określa przetestowaną granicę kompatybilności, odróżnia wdrożenie od daty wydania i daje czytelnikom sposób na weryfikację dostępu.

Galeria projektów

Zachowuj te same fakty dotyczące wydania w każdym wariancie układu, aby przegląd projektu testował hierarchię, a nie różne decyzje redakcyjne.

Lista kontrolna jakości

Notatka wydania jest gotowa tylko wtedy, gdy każde mające zastosowanie stwierdzenie jest prawdziwe:

• Tytuł i otwarcie identyfikują produkt, datę lub wersję, główną zmianę i dotkniętych odbiorców.
• Dostępność jest precyzyjna: wydane, wdrażane z oknem, beta, opcjonalne, ograniczone planem, ograniczone regionem, odroczone lub wycofane.
• Każdy wpis wyjaśnia obserwowalne zachowanie przed i po, zamiast polegać na „ulepszone”, „usprawnione” lub „naprawione”.
• Etykiety Dodano, Zmieniono, Naprawiono, Wycofano, Usunięto i Bezpieczeństwo są stosowane konsekwentnie.
• Zmiany przełomowe pojawiają się przed korzyściami promocyjnymi i określają dotknięty zakres, termin, tryb awarii, zamiennik, migrację, walidację, wycofanie lub ścieżkę wsparcia.
• Daty odróżniają wydanie, publikację, istotną modyfikację, wycofanie i usunięcie.
• Identyfikatory wersji, nazwy endpointów, etykiety menu, plany, regiony i zakres platform zostały zweryfikowane względem wydanego stanu.
• Czytelnik może stwierdzić, czy działanie jest wymagane i jak potwierdzić jego wykonanie.
• Bieżąca dokumentacja odzwierciedla nowe zachowanie i linkuje z powrotem do odpowiedniego wydania, gdy historia ma znaczenie.
• Zrzuty ekranu mają datę przechwycenia lub wersję oraz tekstowy odpowiednik dla pokazywanych elementów sterujących lub stanów.
• Archiwum zapewnia stabilne URL lub kotwice, przeglądanie od najnowszych i sposób dotarcia do starszych wpisów.
• Odpowiedzi FAQ w frontmatter i widoczne odpowiedzi FAQ są zgodne co do joty, a analityka odróżnia przeglądanie od migracji lub działania produktowego.

Częste błędy

Pisanie kopii kampanii zamiast zapisu. „Jesteśmy zachwyceni, mogąc przekształcić Twój przepływ pracy” opóźnia fakty. Rozpocznij od wydanego zachowania, odbiorców, dostępności i działania; narrację umieść w osobnym ogłoszeniu premiery.

Chowanie zmian przełomowych. Termin migracji poniżej zrzutów ekranu i korzyści prowadzi do możliwych do uniknięcia awarii. Umieść ostrzeżenie jako pierwsze i uczyń je niezależnie zrozumiałym.

Nazywanie wdrożenia premierą wszędzie. Jeśli tylko niektóre konta mają dostęp, mów o wdrożeniu i podaj przewidywane okno. Użytkownicy tracą zaufanie, gdy instrukcje opisują element sterujący, którego jeszcze nie widzą.

Używanie „poprawki błędów i ulepszenia”. Ukrywa to dotknięte zachowanie i uniemożliwia użytkownikom rozpoznanie, że ich problem został rozwiązany. Określ objaw, zakres i nowy stan, chyba że ujawnienie kwestii bezpieczeństwa wymaga powściągliwości.

Zmienianie dat dla aktualności. Poprawka literówki nie czyni starego wydania nowym. Zachowaj releasedAt, zarejestruj istotną poprawkę osobno i używaj lastmod tylko wtedy, gdy widoczny zapis zmienił się znacząco.

Powielanie bieżących instrukcji. Długa procedura konfiguracji będzie się rozjeżdżać w dwóch miejscach. Podsumuj zmieniony krok w notatce wydania i pozwól, aby utrzymywana dokumentacja posiadała pełny bieżący przepływ pracy.

Linkowanie wewnętrzne

Dobre linkowanie wewnętrzne czyni dziennik zmian historyczną warstwą wiedzy o produkcie. Linkuj z bieżącej dokumentacji, gdy przejście wyjaśnia zmienione zachowanie. Linkuj z wydania do dokładnej dokumentacji, migracji, rozwiązywania problemów, polityki lub wskazówek kompatybilności, gdzie użytkownik tego potrzebuje.

Używaj jednego kanonicznego zapisu dla każdej istotnej zmiany. Post z premiery, strona funkcji lub odpowiedź wsparcia mogą go cytować; żaden nie powinien go kopiować. Nawigacja archiwum powinna łączyć sąsiednie wydania i indeks. W przypadku wycofań linkuj stary wpis do jego zamiennika, a wskazówki migracyjne z powrotem do powiadomienia.

Jak mierzyć wyniki

Mierz, czy użytkownicy znajdują właściwy zapis, rozumieją wpływ, wykonują wymagane działanie i potrzebują mniej wyjaśnień. Surowe odsłony nie są celem: mała poprawka może spełnić swoje zadanie przy niewielkim ruchu.

Użyj śledzenia promptów dla pytań o produkt i wersję, zmienionych nazw funkcji, dat wycofań i sformułowań „najnowsza aktualizacja”. Użyj inteligencji źródeł i cytowań , aby sprawdzić, czy odpowiedzi AI cytują kanoniczny wpis i zachowują dostępność, dotknięty zakres, termin i wymagane działanie. Kokpit AmICited może umieścić widoczność związaną z wydaniem i cytowane URL obok aktywności organicznej na stronie lądowania i wybranych zdarzeń produktowych.

Przed publikacją zapisz dotkniętych odbiorców, okno wdrożenia, wolumen wsparcia, linię bazową migracji, docelowe zapytania i prompty oraz zdarzenie, które dowodzi sukcesu. Sprawdź:

• wyświetlenia i wizyty dla zapytań o produkt, wersję, funkcję, wycofanie i dziennik zmian;
• cytowania AI, które odtwarzają poprawną datę wydania, status, granicę kompatybilności i działanie;
• odsłony kotwic lub stron na poziomie wpisu, a nie tylko widoki indeksu dziennika zmian;
• kliknięcia w zaktualizowaną dokumentację, migrację, rozwiązywanie problemów lub ścieżki weryfikacji;
• rozpoczęcia migracji, ukończenia walidacji i pozostałe użycie starszej wersji, jeśli istnieje prywatna telemetria;
• zgłoszenia wsparcia spowodowane niejasnym zakresem, brakiem dostępu do wdrożenia lub nieudokumentowanym zachowaniem;
• nieaktualne odpowiedzi po poprawce, wycofaniu, zastępującym wydaniu lub zmianie terminu.

Postępuj zgodnie z jak mierzymy wyniki , aby oddzielić odkrywanie, cytowanie, zaangażowanie, realizację zadań, retencję i wyniki biznesowe. Adnotuj premiery, incydenty, kampanie i obowiązkowe migracje przed interpretacją zmian. Skok ruchu może wskazywać na zamieszanie, a cytowana odpowiedź jest szkodliwa, jeśli pomija termin zmiany przełomowej.

FAQ

Najczęściej zadawane pytania