como o versionamento semântico se aplica a programas sem API

Em http://semver.org/ - que, na minha opinião, parece ser a convenção mais usada no controle de versão - é recomendável aumentar o número da versão principal quando uma alteração que quebra / modifica a API é introduzida.

Existem dois cenários relacionados, mas não vejo como aplicar essa diretriz:

1. E se o meu código não oferecer nenhuma API? Como devo versão meu código?
2. E se meu código começar a oferecer uma API no estágio final de seu desenvolvimento?

Semver está preocupado principalmente com o controle de versões de bibliotecas e pacotes de uma maneira que evita o inferno das dependências, em suas várias encarnações. No entanto, a idéia por trás do Semver pode ser estendida a todos os tipos de programas - qualquer parte do código tem algum tipo de interface do usuário ou é bastante inútil.

• Uma biblioteca de programação ou serviço da web possui uma API.
• O software do consumidor pode ter uma GUI.
• Os programas de linha de comando têm um conjunto de opções e opções.
• Os arquivos de configuração também são uma interface do usuário.

Usando o exemplo de software de consumidor, como um processador de texto:

• Aumente o número do patch ao enviar uma correção de bug, por exemplo: “ bug corrigido em que o aplicativo sempre falha às 00:00 PM às terças-feiras ”.
• Incremente o número da versão secundária ao adicionar um novo recurso, por exemplo: “ suporte adicionado para texto sublinhado ”.
• Incremente a versão principal quando você revisar significativamente a interface do usuário ou reescrever todos os componentes internos. Por exemplo: “As barras de ferramentas usam muito espaço na tela. A interface do usuário agora é fornecida apenas por gestos de toque ”- essa alteração interromperia os fluxos de trabalho existentes.

No entanto, muitos problemas que Semver tenta resolver não existem fora da área de gerenciamento de dependências. Nos aplicativos de consumidor, a versão não é apenas uma versão, mas também um ativo de marketing.

• O Firefox e o Chrome lançam novas versões comparativamente com frequência e aumentam o número da versão principal a cada lançamento. Isso resulta em números de versão ridiculamente altos (ambos estão atualmente nos 30 anos). Um navegador com um número de versão superior deve simplesmente ser melhor do que um navegador com um número de versão inferior, certo?

• O número da versão principal do sistema operacional OS X da Apple se tornou parte do nome (X é 10 em algarismos romanos), tornando o número da versão secundária o número efetivo da versão principal.

• O sistema operacional Ubuntu usa um esquema de versão year.month.patchlevel. Isso facilita lembrar a idade do seu sistema operacional, mas torna muito mais difícil descobrir quais versões são compatíveis e quanto tempo dura o suporte para cada versão.

• O kernel do Linux aumentou o número da versão de 2.6.39 para 3.0.0, porque 39estava ficando um pouco grande e para comemorar o 20º aniversário do Linux.

• O lendário sistema de tipografia TeX de Donald Knuth usa um número de versão que, a partir da versão 3, converge para π adicionando outro dígito a cada lançamento: 3.14159265…. Isso significa como o sistema está se aproximando da perfeição. Da mesma forma, o sistema Metafont converge para e : 2.7182818….

Portanto, muitos aplicativos não são bem servidos pela Semver. Escolha um esquema de versão que seja bom para seus usuários (independentemente de serem usuários programadores ou consumidores) e mantenha-o consistente.