Notas de lançamento e changelog

Notas de lançamento são o registro datado e de primeira parte de uma mudança no produto: o que foi lançado, quem afeta, o que se comporta de forma diferente e o que o usuário deve fazer em seguida. Um changelog é a coleção cronológica dessas entradas. O formato é uma ferramenta de retenção antes de ser um ativo de tráfego; os clientes o utilizam para planejar o trabalho e evitar surpresas.

A regra fundamental é consequência antes da celebração. Um lançamento pode ser empolgante para a equipe, mas o leitor precisa primeiro saber se seu fluxo de trabalho, integração, dados, permissões, preço ou compatibilidade mudaram. Declare essa consequência em linguagem simples, depois explique a capacidade. Dentro do sistema de tipos de post SEO , as notas de lançamento são conteúdo de suporte no estágio de retenção; seu valor vem de registros permanentes que nunca são reescritos silenciosamente.

Perguntas que responde

Uma entrada completa de nota de lançamento responde às perguntas que um usuário atual faz ao ver uma mudança no produto ou encontrar um comportamento desconhecido:

• O que mudou, e em qual data de lançamento ou versão?
• A mudança está disponível agora, sendo implementada gradualmente, em beta, ou limitada por plano, região, plataforma ou tipo de conta?
• Quem é afetado, incluindo administradores, usuários finais, desenvolvedores, parceiros ou uma integração definida?
• Qual era o comportamento anterior e o que é diferente agora?
• O usuário precisa migrar, atualizar configurações, reautorizar acesso, retreinar colegas ou não tomar nenhuma ação?
• A mudança é crítica, obsoleta, reversível, sensível à segurança ou provável de alterar dados armazenados?
• Onde estão as instruções atualizadas, referência técnica, limitações conhecidas e rota de suporte?
• Como o leitor pode verificar se o novo comportamento está ativo em sua conta?

Não faça os leitores inferirem impacto a partir de rótulos como “melhorado”, “atualizado” ou “otimizado”. “Exportações foram melhoradas” é promocional, mas não verificável. “Exportações CSV agora incluem os filtros de país e modelo aplicados em duas novas colunas; colunas existentes e a ordem permanecem inalteradas” define a mudança observável e seu limite de compatibilidade.

Quando usar este tipo de post

Use notas de lançamento quando um evento foi lançado ou tem um estado de disponibilidade definido e cria uma diferença visível ao usuário que vale a pena preservar no histórico do produto. A intenção de busca geralmente é navegacional ou informacional: os leitores buscam um produto mais “notas de lançamento”, um número de versão, uma funcionalidade alterada, uma descontinuação ou um rótulo de interface desconhecido. Não use o formato como um backlog de promessas, um feed de anúncios gerais ou um substituto para documentação de tarefas.

Uma mudança não precisa de uma nova interface para se qualificar. Comportamento de API, retenção, cálculos, autenticação, formatos, limites, padrões, faturamento e acessibilidade podem exigir uma entrada. Uma refatoração interna sem consequência observável não exige.

Melhor para estes tipos de negócio

A classificação reflete a necessidade de manter um contrato público datado com os usuários existentes.

1. SaaS . A melhor adequação porque interfaces, APIs, permissões, integrações e limites de plano entregues continuamente podem mudar entre visitas de clientes. As entradas devem incluir estado de implementação, planos afetados, impacto no administrador e links para documentação.
2. Marketplaces . Alto valor porque um lançamento pode afetar compradores, vendedores, moderadores, recebedores de pagamento ou parceiros de forma diferente. Segmente o impacto e evite apresentar uma mudança específica a um participante como universal.
3. Ecommerce . Útil para mudanças em conta, checkout, assinatura, devoluções, fidelidade, entrega e ferramentas de comerciante. Separe o impacto no cliente da loja do impacto no operador ou integração, especialmente em relação a pagamentos e status de pedidos.
4. Fabricantes e fornecedores industriais . Importante para firmware, software de controle, equipamentos conectados, portais técnicos e revisões de especificações. Versão, compatibilidade de modelo, limites de segurança e disponibilidade de reversão devem ser explícitos.
5. Finanças, fintech e seguros . Valioso, mas com revisão intensiva porque mudanças em cálculos, elegibilidade, divulgação, autenticação e manipulação de dados podem ter consequências regulatórias. Registre jurisdição, aprovação, data de vigência e comportamento substituído.
6. Serviços B2B . Seletivamente útil quando o serviço inclui uma plataforma mantida, metodologia, conjunto de dados, portal do cliente ou entrega padrão. Notícias comuns da empresa pertencem a outro lugar, a menos que alterem o contrato do cliente ou fluxo de trabalho.

Intenção de busca

A demanda por notas de lançamento é frequentemente de baixo volume e alta especificidade. As consultas incluem um nome de produto com “changelog”, “última versão”, “o que mudou”, “novo painel”, uma versão de API, um erro introduzido após uma atualização ou uma data de descontinuação. O pesquisador não está pedindo uma apresentação ampla do produto. Eles querem um timestamp autoritativo e detalhes suficientes para tomar uma decisão.

O formato útil do resultado começa com produto + versão ou data + mudança + impacto. Coloque esses fatos no título, resumo de abertura, cabeçalhos e metadados sem forçar cada entrada menor a uma URL indexável própria. Âncoras estáveis permitem que equipes de suporte e respostas de IA citem uma entrada; páginas dedicadas são justificadas quando um lançamento tem trabalho de migração substancial, demanda distinta ou várias mudanças relacionadas.

Notas de lançamento são um sinal de atualidade subestimado porque expõem mudança real no ritmo em que ocorre. Isso não justifica alterar datas para parecer ativo. A data da entrada, documentação atual, comportamento do produto e orientação de migração devem estar em concordância.

Estrutura da página

As faixas de palavras definem ênfase, não cotas. Preserve a mesma ordem de campos para que os leitores possam escanear pequenas correções e lançamentos críticos igualmente.

Agrupe mudanças com rótulos estáveis como Adicionado, Alterado, Corrigido, Obsoleto, Removido, Segurança, mas nunca deixe um rótulo substituir a explicação. “Corrigido: exportações” não é um registro útil. Cada item deve nomear o sintoma ou limitação anterior, o novo estado observável, o escopo afetado e qualquer ação necessária.

Elementos obrigatórios

A posição faz parte do controle de risco: um aviso de migração mostrado após a celebração da funcionalidade chega tarde demais.

Frontmatter e dados estruturados

Siga a especificação de frontmatter . Esta página do playbook usa entity = "post-type-release-notes". Um changelog produzido deve usar um valor estável de produto-e-stream, como entity = "atlas-cloud-release-notes"; um lançamento individual pode usar entity = "atlas-cloud-2026-08". Não use um slogan de campanha ou título de lançamento mutável como identificador.

Use schemaType = "Article" para uma página de nota de lançamento individual. Se o site expõe um índice como uma entidade distinta, CollectionPage pode descrever esse índice enquanto cada entrada material permanece um item datado visível. Adicione FAQPage apenas quando a FAQ está visível e é suportada pela implementação. Não use HowTo meramente porque as instruções de migração contêm etapas, e não marque um produto como recém-lançado quando a página apenas corrigiu a redação.

Armazene a data de lançamento separadamente das datas de publicação e modificação. Campos recomendados incluem product, stream, version, status, releasedAt, platforms, plans, regions, affected roles, breakingChange, actionRequired, deprecationDate, owner, canonical URL e documentation targets. Para uma implementação em fases, mantenha uma data de lançamento e declare a janela no texto visível.

Exemplo completo

O exemplo fictício abaixo demonstra um lançamento material. Ele mantém a consequência da migração à frente do resumo da funcionalidade e usa uma URL de versão estável.

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

# Notas de lançamento do Atlas Cloud 4.8

O Atlas Cloud 4.8 começou a ser implementado em 27 de agosto de 2026. Ele adiciona visualizações de exportação salvas e a Export API v2. Membros do workspace podem usar visualizações salvas sem alterar exportações existentes. Proprietários de integração que usam a API v1 devem migrar antes de 15 de outubro de 2026; após essa data, requisições de exportação v1 retornarão uma resposta de versão não suportada.

## Ação necessária: migrar a Export API v1

**Quem é afetado:** integrações que enviam requisições para `/api/v1/exports`. Exportações do painel e clientes da API v2 não são afetados.

**O que muda:** a v2 exige um valor `format` explícito e retorna o identificador do job de exportação em `data.id`. As colunas do arquivo não mudam, a menos que uma visualização salva selecione um conjunto diferente de campos.

**Prazo:** concluir a migração e validação antes de 15 de outubro de 2026. Requisições v1 existentes continuam funcionando até lá.

1. Crie uma requisição de teste contra o endpoint v2 com os mesmos filtros de uma requisição v1 atual.
2. Adicione o valor `format` necessário e leia o identificador do job de `data.id`.
3. Compare a contagem de linhas, conjunto de campos, fuso horário e um registro conhecido entre os arquivos antigo e novo.
4. Atualize a produção somente após a comparação ser bem-sucedida. Mantenha a configuração anterior disponível até que a primeira exportação programada em produção seja bem-sucedida.

Se o teste não corresponder, mantenha a integração de produção na v1 e envie ao suporte o ID da requisição sanitizada, timestamp, fuso horário e a divergência de campo. Não inclua um token de acesso.

## Adicionado: visualizações de exportação salvas

Administradores do workspace podem salvar um conjunto nomeado de campos, filtros, ordenação e formato de arquivo. Membros com permissão de exportação podem reutilizar a visualização; salvar uma visualização não concede acesso a registros que eles já não poderiam ver.

Para verificar a disponibilidade, abra **Exportações → Visualizações** e procure por **Salvar visualização atual**. O controle pode levar até três dias para aparecer durante a implementação. Está incluído nos planos Standard e Enterprise em todas as regiões.

## Corrigido: rótulos de filtro de país em arquivos CSV

Exportações CSV agora usam o nome visível do país na coluna de resumo do filtro em vez do valor interno de duas letras. Isso altera apenas o rótulo do resumo; registros filtrados e colunas de dados existentes permanecem inalterados.

## Limitações conhecidas

Visualizações salvas ainda não podem ser transferidas entre workspaces. Um campo excluído é removido da visualização na próxima vez que ela for executada, e o histórico de exportação registra essa omissão.

## Recursos atualizados

- Guia de migração da Export API v2
- Referência da Export API
- Documentação de permissões de exportação
- Solução de problemas de exportação

O exemplo nomeia um limite de compatibilidade testado, distingue implementação de data de lançamento e dá aos leitores uma maneira de verificar o acesso.

Galeria de design

Mantenha os mesmos fatos do lançamento em cada variante de layout para que a revisão de design teste hierarquia, e não diferentes decisões editoriais.

Lista de verificação de qualidade

Uma nota de lançamento está pronta somente quando cada afirmação aplicável é verdadeira:

• O título e a abertura identificam o produto, data ou versão, mudança principal e público afetado.
• A disponibilidade é precisa: lançado, em implementação com janela, beta, opt-in, limitado por plano, limitado por região, adiado ou retirado.
• Cada entrada explica o comportamento observável antes e depois, em vez de depender de “melhorado”, “aprimorado” ou “corrigido”.
• Rótulos de adicionado, alterado, corrigido, obsoleto, removido e segurança são aplicados de forma consistente.
• Alterações críticas aparecem antes dos benefícios promocionais e declaram o escopo afetado, prazo, modo de falha, substituto, migração, validação, reversão ou rota de suporte.
• As datas distinguem lançamento, publicação, modificação material, descontinuação e remoção.
• Identificadores de versão, nomes de endpoint, rótulos de menu, planos, regiões e escopo de plataforma foram verificados em relação ao estado lançado.
• O leitor pode saber se uma ação é necessária e como confirmar a conclusão.
• A documentação atual reflete o novo comportamento e linka de volta ao lançamento relevante onde o histórico é importante.
• Capturas de tela têm uma data de captura ou versão e um equivalente textual para os controles ou estados que mostram.
• O arquivo fornece URLs ou âncoras estáveis, navegação do mais recente primeiro e uma maneira de alcançar entradas mais antigas.
• As respostas da FAQ no frontmatter e as respostas visíveis da FAQ correspondem exatamente, e a análise distingue navegação de migração ou ação no produto.

Erros comuns

Escrever texto de campanha em vez de um registro. “Estamos entusiasmados em transformar seu fluxo de trabalho” atrasa o fato. Comece com o comportamento lançado, público, disponibilidade e ação; coloque a narrativa em um anúncio de lançamento separado.

Enterrar alterações críticas. Um prazo de migração abaixo de capturas de tela e benefícios cria falhas evitáveis. Coloque o aviso primeiro e torne-o compreensível de forma independente.

Chamar uma implementação de lançamento em toda parte. Se apenas algumas contas têm acesso, diga implementação e dê a janela esperada. Os usuários perdem confiança quando as instruções descrevem um controle que eles ainda não podem ver.

Usar “correções de bugs e melhorias”. Isso esconde o comportamento afetado e impede que os usuários reconheçam que seu problema foi resolvido. Nomeie o sintoma, escopo e novo estado, a menos que a divulgação de segurança exija contenção.

Alterar datas por atualidade. Uma correção de digitação não torna um lançamento antigo novo. Preserve releasedAt, registre uma correção material separadamente e use lastmod apenas quando o registro visível mudou significativamente.

Duplicar instruções atuais. Um procedimento de configuração longo se desviará em dois lugares. Resuma a etapa alterada na nota de lançamento e deixe a documentação mantida ser a dona do fluxo de trabalho completo atual.

Linkagem interna

Uma boa linkagem interna torna o changelog a camada histórica do conhecimento do produto. Link a partir da documentação atual quando uma transição explica o comportamento alterado. Link do lançamento para a documentação exata, migração, solução de problemas, política ou orientação de compatibilidade onde o usuário precisar.

Use um registro canônico para cada mudança material. Um post de lançamento, página de funcionalidade ou resposta de suporte pode citá-lo; nenhum deve copiá-lo. A navegação do arquivo deve conectar lançamentos adjacentes e o índice. Para descontinuações, link a entrada antiga ao seu substituto e a orientação de migração de volta ao aviso.

Como medir resultados

Meça se os usuários descobrem o registro certo, entendem o impacto, completam a ação necessária e precisam de menos esclarecimento. Visualizações brutas de página não são o objetivo: uma pequena correção pode cumprir seu propósito com pouco tráfego.

Use o monitoramento de prompts para perguntas de produto-mais-versão, nomes de funcionalidades alteradas, datas de descontinuação e a expressão “última atualização”. Use a inteligência de fontes e citações para inspecionar se as respostas de IA citam a entrada canônica e preservam disponibilidade, escopo afetado, prazo e ação necessária. O AmICited Cockpit pode posicionar a visibilidade relacionada a lançamentos e URLs citadas ao lado da atividade orgânica de destino e eventos selecionados do produto.

Antes de publicar, registre o público afetado, janela de implementação, volume de suporte, linha de base de migração, consultas e prompts alvo e o evento que prova o sucesso. Revise:

• impressões e visitas para consultas de produto, versão, funcionalidade, descontinuação e changelog;
• citações de IA que reproduzem a data de lançamento, status, limite de compatibilidade e ação corretos;
• visualizações de âncora ou página no nível da entrada, em vez de apenas visualizações do índice do changelog;
• cliques em documentação atualizada, migração, solução de problemas ou caminhos de verificação;
• inícios de migração, conclusões de validação e uso legado restante onde existir telemetria segura para privacidade;
• contatos de suporte causados por escopo pouco claro, falta de acesso à implementação ou comportamento não documentado;
• respostas desatualizadas após uma correção, retirada, lançamento substituto ou mudança de prazo.

Siga como medimos resultados para separar descoberta, citação, engajamento, conclusão de tarefa, retenção e resultados de negócio. Anote lançamentos, incidentes, campanhas e migrações obrigatórias antes de interpretar movimentos. Um pico de tráfego pode indicar confusão, e uma resposta citada é prejudicial se omitir o prazo da alteração crítica.

FAQ

Perguntas frequentes