Validar a sintaxe ou justificar o incremento da versão?
SemVer verifica apenas sintaxe. Decida a compatibilidade pelas alterações reais; use a revisão de versões de API quando contratos forem modificados.
Elysia Tools
Navegação
Workflow Playbook
Revise uma versão pelo registro de alterações, valide a sintaxe e as referências Markdown e prepare notas consistentes para site, Slack e PDF.
Temas
Este fluxo atende responsáveis que entregam uma versão de software a revisores e encarregados dos anúncios. Comece pelo registro oficial e uma versão definida, não por mensagens de alterações misturadas. Extraia as seções, confira datas e categorias e compare as entradas com evidências aprovadas. Uma seção vazia pode indicar formato não reconhecido, não ausência de mudanças. Não inclua automaticamente todos os itens ainda não publicados.
Explique o que mudou, quem precisa agir e quais orientações de migração ou reversão estão aprovadas. Sintaxe SemVer válida não justifica um incremento secundário. Resolva isso antes da publicação. O verificador de estilo localiza defeitos de formato; correções seguras não substituem a revisão de títulos, exemplos de código e explicações incompletas. Fixe a revisão de origem antes de criar variantes.
Notas curtas normalmente dispensam sumário. Para documentos longos, finalize os títulos antes de gerá-lo e confira as referências depois. As âncoras seguem convenções do GitHub; teste-as no renderizador real do site. Uma verificação estática não comprova que um download está disponível. Abra os destinos externos importantes separadamente e confira exigências de autenticação.
Produza apenas os formatos necessários. Uma tabela extensa pode permanecer nas notas completas; no Slack, mantenha um resumo legível com avisos de migração e link oficial. Reescreva tabelas, listas de tarefas e explicações dependentes de imagens quando forem sinalizadas como não suportadas. Converter não equivale a implantar o site nem enviar mensagens.
Quando houver necessidade de PDF, examine páginas reais para encontrar tabelas cortadas, código fora das margens e contexto perdido nas quebras. Compare versão, data, instruções e links de cada entrega com o documento principal. Regenere variantes antigas em vez de corrigir só o arquivo exportado. Registre revisão aprovada e nomes de arquivos juntos. Manuais amplos pertencem ao fluxo de documentação; ajustes isolados, aos utilitários Markdown. A compatibilidade de contratos deve ser decidida na revisão de versões de API antes desta entrega.
Guia de fluxo de trabalho
Extraia versões e alterações classificadas, selecione a publicação prevista, compare com as evidências e valide o identificador sem tratar sintaxe como prova de compatibilidade.
Corrija problemas de formatação, examine títulos e blocos de código manualmente e complete explicações de mudanças e migração.
Gere um sumário apenas quando útil; depois verifique âncoras internas, formatos e referências indefinidas. Teste URLs externas e âncoras específicas do destino separadamente.
Converta o documento aprovado para HTML e o anúncio para Slack mrkdwn, adapte elementos não suportados e compare fatos essenciais antes da entrega, sem publicação automática.
SemVer verifica apenas sintaxe. Decida a compatibilidade pelas alterações reais; use a revisão de versões de API quando contratos forem modificados.
Dispense-o em anúncios curtos. Em notas extensas, finalize os títulos antes de gerar a navegação e teste as âncoras no destino.
Preserve o contexto no site ou PDF. Encurte o Slack sem perder avisos de migração e o link oficial; adapte tabelas e listas de tarefas não suportadas.
Exporte um PDF com tema adequado, confira paginação e leitura e compare os arquivos necessários com a mesma revisão aprovada.