Política de versionamento

O Oxlint segue versionamento semver para deixar upgrades previsíveis.

Breaking inclui:

• Mudanças na CLI que quebrem fluxos existentes
• Mudanças no formato de config (.oxlintrc.json) que quebrem setups
• Renomear ou remover regra

Não são breaking:

• Novas regras
• Mudar config padrão de uma regra
• Melhorar descrição ou texto de diagnóstico
• Novas opções em regras existentes
• Correções que alinham comportamento ao ESLint original
• Novos campos no arquivo de config

Fora do semver

Podem mudar a qualquer momento (até em patch):

• Plugins JS customizados — API e comportamento podem mudar
• Lint com tipos — regras e comportamento evoluem

Novos erros de lint são breaking?

Versões novas podem reportar mais problemas — significa análise melhor, não que o upgrade “quebrou” o projeto. Erros extras refletem regras mais fortes.

O que esperar por tipo de release

• Patch (1.0.x): correções, performance, refactors internos — upgrade seguro
• Minor (1.x.0): regras novas, diagnósticos melhores — não é breaking mesmo se aparecerem novos erros
• Major (x.0.0): breaking de CLI ou formato de config

Com Renovate

renovate.json

{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchPackageNames": ["oxlint"],
      "groupName": "oxlint",
      "automergeType": "branch",
      "stabilityDays": 1
    }
  ]
}

Se usar eslint-plugin-oxlint, atualize junto com o oxlint para evitar incompatibilidade.

Com Dependabot

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/" # onde está o package.json
    schedule:
      interval: "daily"
    groups:
      oxlint:
        patterns:
          - "oxlint"
    commit-message:
      prefix: "chore"
      include: "scope"
    ignore:
      - dependency-name: "oxlint"
        update-types: ["version-update:semver-major"]
    open-pull-requests-limit: 1

Mesma observação: mantenha eslint-plugin-oxlint alinhado ao Oxlint.