Conversor de formatos de versão de pacotes
Cole uma ou mais strings de versão (uma por linha) e veja quais são SemVer válidas, PEP 440 válidas, ambas ou nenhuma — e por que uma versão que parece correta em um ecossistema pode ser rejeitada ou ter outro significado em outro.
O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.
Como usar esta ferramenta ferramenta
- Cole uma ou mais strings de versão, uma por linha; os dados não saem do navegador.
- Selecione ‘Analisar versões’.
- Confira cada valor sinalizado: qual gramática não atende ou qual diferença semântica sutil se aplica, e por quê.
- Use a reescrita sugerida quando disponível. Algumas conversões são apenas aproximações; isso é explicado em vez de ser aplicado silenciosamente.
Premissas
- Reconhece os formatos comuns de duas gramáticas: SemVer 2.0.0 (`MAJOR.MINOR.PATCH[-prerelease][+build]`) e PEP 440 (`[N!]N(.N)*[{a|b|rc}N][.postN][.devN][+local]`). Esquemas incomuns ou específicos de fornecedores (sufixos de época/revisão do Debian, qualificadores Maven) estão fora do escopo.
- Não implementa comparação nem ordenação entre números de versão; verifica somente análise correta, validade e conversões reversíveis seguras.
- Só oferece reescrita inequívoca e sem perda, como remover o prefixo `v` de uma tag Git ou completar uma versão de dois componentes com um terceiro. Sufixos dev/post de PEP 440 não têm equivalente exato em SemVer, portanto não são convertidos automaticamente, embora uma correspondência aproximada seja explicada.
Fontes e dados de referência
Metodologia
Cada linha é analisada pelas duas gramáticas usando expressões regulares derivadas das especificações (a expressão oficial da gramática SemVer 2.0.0 e um padrão PEP 440 que cobre segmentos de época, versão, pré-lançamento, pós-lançamento, desenvolvimento e versão local). Em seguida, verificam-se divergências documentadas: o hífen exigido por SemVer antes de pré-lançamento, mas não por PEP 440; versões dev/post de PEP 440 sem equivalente em SemVer; diferença semântica dos metadados de build (SemVer os ignora na precedência; PEP 440 não ignora a versão local); prefixo `v` de tag Git não esperado por nenhuma gramática; zero inicial inválido em SemVer estrito; e versão de dois componentes aceita por PEP 440, mas não por SemVer.
Exemplo resolvido
Pré-lançamento no estilo Python sem o hífen exigido por SemVer
Dados de entrada: 1.0.0a1
Resultado: Válida em PEP 440 (alfa 1), mas SemVer estrito exige hífen antes de qualquer identificador de pré-lançamento e a rejeita. É sinalizada como erro e oferece a forma SemVer `1.0.0-a1`.
Metadados de build versus versão local PEP 440
Dados de entrada: 1.2.3+build1
Resultado: Texto válido nas duas gramáticas, mas SemVer exige que `+build1` seja ignorado na precedência (`1.2.3+build1` == `1.2.3+build2`), enquanto o segmento de versão local equivalente de PEP 440 afeta a ordenação. É sinalizada como aviso; não há reescrita porque a ambiguidade está nas especificações, não na string.
Sufixo de versão de desenvolvimento PEP 440
Dados de entrada: 1.0.0.dev0
Resultado: Válida em PEP 440 (versão de desenvolvimento anterior a 1.0.0), mas SemVer não tem conceito diretamente equivalente. É sinalizada como erro; explica-se que `1.0.0-dev.0` às vezes é usado como aproximação com regras de precedência diferentes, portanto não é oferecido como conversão automática.
Orientações práticas
- Se um pacote precisa ser publicado com identidade no estilo npm (SemVer) e PyPI (PEP 440), escolha um esquema que atenda à gramática mais estrita: `MAJOR.MINOR.PATCH` com pré-lançamento precedido por hífen (por exemplo, `1.2.3-rc1`) é válido e tem o mesmo significado em ambas.
- Não dependa da ordenação de metadados de build nem de versões locais PEP 440 para decisões importantes: trate essa parte da string como informativa, pois os ecossistemas discordam sobre seu efeito na precedência.
- Remova o prefixo `v` de uma tag Git antes de fornecer a versão a um analisador ou biblioteca de comparação; a remoção é segura e nenhuma das gramáticas espera esse prefixo.
Erros comuns
- Presumir que `1.0.0a1` e `1.0.0-a1` significam a mesma coisa para todas as ferramentas: a primeira só é válida em PEP 440; a segunda é válida em ambas. Um parser SemVer estrito rejeita a primeira em vez de interpretá-la permissivamente.
- Tratar sufixo dev/post de PEP 440 como se tivesse tradução exata em SemVer. Não tem; qualquer correspondência é aproximada e apresenta comportamento de comparação diferente.
Perguntas frequentes
Por que `1.0.0a1` é sinalizada como erro em vez de aviso?
Não é apenas uma forma pouco idiomática: um parser SemVer estrito não consegue analisá-la, assim como um parser JSON falha com vírgula final. É incompatibilidade direta, não preferência de estilo.
Por que a ferramenta não reescreve automaticamente `1.0.0.dev0` para um equivalente SemVer?
Não existe forma com equivalência garantida. As versões dev/post de PEP 440 modelam ‘antes’ e ‘depois’ de uma versão de maneira que os campos de pré-lançamento/build do SemVer não reproduzem exatamente. Qualquer forma SemVer é aproximação com comportamento de ordenação diferente; só se reescreve automaticamente quando não há perda real.
`1.2.3+build1` está realmente quebrada?
Não como texto: é válida nas duas gramáticas. O risco está em como o sufixo de build/versão local afeta a comparação, o que difere entre as ferramentas dos dois ecossistemas.
Uma versão `.dev` PEP 440 pode ser traduzida exatamente para SemVer?
Não há tradução exata garantida. A semântica de ordenação das versões de desenvolvimento PEP 440 não é reproduzida em todos os casos pelos identificadores de pré-lançamento SemVer. Uma forma como `1.0.0-dev.0` pode ser aproximação, não versão equivalente. A ferramenta verifica formatos reconhecidos e notas de portabilidade; não executa resolutores de gerenciadores de pacotes nem compara versões.
Última revisão:
Verificador de gramática, não resolutor completo de versões de gerenciadores de pacotes: reconhece SemVer 2.0.0 e formatos comuns PEP 440, não esquemas específicos de fornecedores (revisões Debian, qualificadores Maven), e não implementa lógica de comparação/ordenação para nenhum dos formatos.
As preferências de tema e de ferramentas, além das listas de itens salvos e usados recentemente, são armazenadas somente neste navegador.