---
sidebar_position: 1
title: "Sobre as Release Notes"
---

# Release Notes

Esta seção registra o histórico de versões da plataforma: o que foi lançado, quando e o que mudou. Cada entrada documenta as alterações introduzidas em uma versão, organizadas por categoria.

## Por que mantemos release notes

Release notes são um contrato de comunicação entre quem desenvolve e quem usa a plataforma. Elas permitem que educadores, gestores e colaboradores técnicos saibam o que mudou sem precisar vasculhar commits ou pull requests. Para a equipe de desenvolvimento, escrever release notes também é um exercício de clareza: força articular o impacto de cada mudança em linguagem compreensível fora do contexto técnico imediato.

## Versionamento

A plataforma adota o [Versionamento Semântico](https://semver.org/lang/pt-BR/) (SemVer), com números no formato `MAJOR.MINOR.PATCH`.

| Componente | Quando incrementar |
|---|---|
| **MAJOR** | Mudanças que transformam a proposta da plataforma, removem funcionalidades existentes ou alteram contratos que afetam integrações externas |
| **MINOR** | Novas atividades, seções pedagógicas, funcionalidades visíveis ao usuário ou recursos técnicos relevantes |
| **PATCH** | Correções de bugs, ajustes de texto, melhorias de performance ou refinamentos que não acrescentam funcionalidade |

O número de versão não é alterado durante o desenvolvimento em branches. Ele é definido no momento em que `develop` é mesclado em `main` — o evento que representa um release no [git-flow](../documentacao/git-flow) do projeto.

## Categorias de mudança

Cada entrada de versão organiza as alterações nas categorias abaixo. Nem toda versão precisa conter todas as categorias.

| Categoria | Descrição |
|---|---|
| **Adicionado** | Novas funcionalidades, atividades ou conteúdo |
| **Modificado** | Mudanças em comportamento ou conteúdo já existente |
| **Corrigido** | Correções de comportamentos incorretos |
| **Removido** | Funcionalidades ou conteúdo retirados |
| **Segurança** | Correções de vulnerabilidades |
| **Descontinuado** | Funcionalidades que serão removidas em versões futuras |

## Boas práticas ao registrar uma versão

- **Escreva para quem usa, não para quem desenvolveu.** Evite referências a nomes de branches, commits ou detalhes de implementação sem significado fora do código.
- **Seja específico.** "Melhoria de performance" não diz nada; "redução do tempo de carregamento inicial das atividades de letramento" diz.
- **Registre no momento do merge.** Lembranças de decisões técnicas se perdem rapidamente depois que o foco muda.
- **Indique o escopo quando relevante.** Se uma mudança afeta apenas um subsistema (por exemplo, somente o JupyterLite ou somente as atividades de letramento), diga isso explicitamente para que leitores de outras trilhas saibam que não são afetados.
- **Separe o que é visível ao usuário do que é técnico.** Mudanças de infraestrutura e refatorações pertencem à seção técnica; novas atividades e novos recursos pedagógicos têm mais peso na comunicação com educadores.

## Versões

```mermaid
gitGraph
    commit id: "repositório criado"
    branch develop
    checkout develop
    commit id: "desenvolvimento inicial"
    commit id: "atividades e documentação"
    checkout main
    merge develop id: "1.0.0 — Lançamento do Decoda" tag: "v1.0.0"
    checkout develop
    commit id: "ordenação, offline, segurança"
    checkout main
    merge develop id: "1.1.0 — Release" tag: "v1.1.0"
    checkout develop
    commit id: "analytics, detecção de atualizações"
    checkout main
    merge develop id: "1.1.3 — Analytics e atualização" tag: "v1.1.3"
```

## Histórico de Versões

| Versão | Data | Destaque Principal |
|---|---|---|
| [**v1.1.3**](v1.1.3.md) | 05/06/2026 | Analytics com Google Analytics 4 e detecção de atualizações automáticas |
| [**v1.1.0**](v1.1.0.md) | 14/07/2026 | Atividade de Ordenação, suporte offline (PWA) e segurança XSS |
| **v1.0.0** | — | Lançamento inicial da plataforma |
