chore: release 2.4.0 + notas de release a partir do CHANGELOG - #34
Merged
Conversation
Tres PRs foram mergeados desde a v2.3.0 - dois deles de seguranca - sem que ninguem bumpasse a versao, entao o workflow de release nunca disparou e as correcoes ficaram sem release publicada. Este commit oficializa a 2.4.0. Junto, muda de onde saem as notas: em vez de --generate-notes (lista crua de PRs mergeados), a release passa a usar a secao correspondente do CHANGELOG.md. Quem le uma release quer saber o que mudou e por que, nao a sequencia de merges - e uma correcao de seguranca precisa aparecer como tal. Se a secao nao existir, o workflow emite um aviso e cai para o comportamento anterior, entao nada trava. O CHANGELOG nasce com o historico das versoes 1.0.0 a 2.4.0. CONTRIBUTING passa a mandar usar `npm version --no-git-tag-version`: o bump precisa alcancar os package-lock.json, senao o npm ci do CI falha.
Contributor
There was a problem hiding this comment.
Pull request overview
Officializes the v2.4.0 release across backend/frontend and updates the release process so GitHub Releases pull their body from the matching CHANGELOG.md section (with a fallback to generated notes).
Changes:
- Bump versions to 2.4.0 in backend and frontend (including lockfiles).
- Add CHANGELOG.md in Keep a Changelog format and update docs to reference it as the release notes source.
- Update the release workflow to extract notes from CHANGELOG, falling back to
--generate-noteswhen missing.
Reviewed changes
Copilot reviewed 7 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| README.md | Documents that releases use the matching CHANGELOG section (with fallback). |
| README.en.md | English equivalent documentation update. |
| CONTRIBUTING.md | Adds release/version bump procedure and CHANGELOG requirement. |
| CHANGELOG.md | New changelog containing version history up to 2.4.0. |
| .github/workflows/release.yml | Extracts release notes from CHANGELOG before creating the GitHub Release. |
| backend/package.json | Bumps backend version to 2.4.0. |
| backend/package-lock.json | Updates backend lockfile version fields to 2.4.0. |
| frontend/package.json | Bumps frontend version to 2.4.0. |
| frontend/package-lock.json | Updates frontend lockfile version fields to 2.4.0. |
Files not reviewed (2)
- backend/package-lock.json: Generated file
- frontend/package-lock.json: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+55
to
+60
| if [ -f CHANGELOG.md ] && grep -q "^## \[$VERSION\]" CHANGELOG.md; then | ||
| awk -v v="$VERSION" ' | ||
| $0 ~ "^## \\[" v "\\]" { found = 1; next } | ||
| found && /^## \[/ { exit } | ||
| found { print } | ||
| ' CHANGELOG.md > release-notes.md |
| ``` | ||
|
|
||
| Se o PR merece uma nova versão (`feat`/`fix` relevantes), bump `backend/package.json` **e** `frontend/package.json` juntos, no mesmo PR — veja [Versionamento](README.md#versionamento) no README. A tag e a release são criadas automaticamente ao mergear. | ||
| Se o PR merece uma nova versão (`feat`/`fix` relevantes), bump `backend/package.json` **e** `frontend/package.json` juntos, no mesmo PR — use `npm version <x.y.z> --no-git-tag-version` em cada um, para os `package-lock.json` acompanharem (senão o `npm ci` do CI falha). Adicione também a seção da versão no [CHANGELOG.md](CHANGELOG.md): é ela que vira o corpo da release. Veja [Versionamento](README.md#versionamento) no README. A tag e a release são criadas automaticamente ao mergear. |
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.
O problema
Desde a v2.3.0 foram mesclados três PRs — #30 e #31 são correções de
segurança — e nenhum deles bumpou a versão. Como o workflow de release só
dispara quando
backend/package.jsonmuda na main, ele nunca rodou: as duascorreções de segurança e toda a internacionalização estão na main há horas sem
release publicada, e o badge de release no README continua mostrando v2.3.0.
O que este PR faz
Oficializa a 2.4.0. Bump em backend e frontend via
npm version --no-git-tag-version, para ospackage-lock.jsonirem junto — onpm cido CI falha se package.json e lock divergirem, e foi assim que orelease 2.3.0 foi feito.
Muda de onde saem as notas. Antes era
--generate-notes, que produz alista crua de PRs mesclados. Agora a release usa a seção correspondente do
CHANGELOG.md. Quem abre uma release quer saber o que mudou e por quê — e umacorreção de segurança precisa aparecer identificada como tal, não diluída entre
merges. Se a seção da versão não existir no CHANGELOG, o workflow emite um
::warning::e cai para o comportamento anterior, então nada trava.Cria o CHANGELOG.md com o histórico das versões 1.0.0 a 2.4.0, no formato
Keep a Changelog, agrupando por Segurança / Adicionado / Corrigido.
Documenta o passo que faltava. O CONTRIBUTING agora manda usar
npm version --no-git-tag-version(por causa do lock) e adicionar a seção noCHANGELOG. Os dois READMEs foram atualizados para descrever de onde vêm as
notas.
Verificação
awkdo workflow: aseção 2.4.0 sai com 42 linhas e termina certo no
## [2.3.0]; uma versãoinexistente cai no fallback como esperado
.github/workflows/release.ymlvalidado como YAMLnpm test→ 25 passam · frontendnpm test→ 7 passamvite buildok, e o bundle carrega2.4.0(a versão exibida na UI vem dopackage.jsonem tempo de build)Observação sobre o histórico de tags
Existe um buraco: as tags vão de
v1.0.0parav2.1.0, semv2.0.0. A versão2.0 circulou no código antes da automação de release existir, então nunca houve
tag. Não criei uma retroativa — uma tag que não corresponde a um ponto real de
publicação engana mais do que ajuda. Se preferir fechar a lacuna, dá para criar
apontando para o commit que subiu a 2.0, mas é uma decisão sua.