Repository navigation
fix(docs): keep stable release overrides above shared development content - #134
Merged
Merged
Conversation
…anuals Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
Ao montar o manual de uma release estável,
source_tree()copiava primeiroversioned/base/e depois os diretórios compartilhados do manual de desenvolvimento. Isso fazia com quedeveloper_manual/integration/_native-webhooks.incda linha de desenvolvimento substituísse o aviso estável de polling nas versões 13, 14 e 15.Correção
Muda a ordem para shared → stable base → overlay por major. Os trechos reutilizáveis continuam sendo herdados, mas o aviso intencional de uma release estável prevalece. O overlay específico da próxima versão mantém precedência máxima.
O teste existente de
tests/test_shared_sources.pyfoi reforçado: a fixture contém um aviso diferente no compartilhado, e asserções verificam as três origens (estável, próxima major e desenvolvimento). Assim a regressão falha com o código anterior.Relação com outros PRs
Esta correção pontual já estava incluída no PR #130, que também possui documentação extensa de webhooks ainda em rascunho. Foi extraída para permitir corrigir imediatamente o vazamento entre versões, sem antecipar a publicação de recursos não estáveis. Ao retomar o #130, remover/reconciliar o trecho idêntico na rebase; não duplicar a implementação.
Validação
Escopo
Sem alterações no conteúdo de webhooks, na API da aplicação ou na publicação do futuro LibreSign 16.