Backbone: Siga SemVer

Obrigado, mas seguir estritamente o versionamento "semântico" não funcionaria muito bem para o Backbone. Dado que o projeto é quase toda área de superfície, e muito pouco interno, quase qualquer alteração dada (patch, solicitação de pull) para Backbone quebra a compatibilidade com versões anteriores de alguma forma ... mesmo que apenas para as pessoas que dependem de um comportamento previamente indefinido.

Se seguíssemos estritamente o controle de versão "semântico", provavelmente seria

Então, como eu gosto de brincar - não versão "semântica", _versão romântica_.

Dado um número de versão MAJOR.MINOR.PATCH, incremente:

Versão PRINCIPAL quando você faz um novo lançamento importante ou atualiza e / ou estabiliza significativamente a API.
Versão MINOR quando você adiciona novos recursos menores.
Versão PATCH quando você faz pequenas alterações, provavelmente passarão despercebidas pela maioria.

Isso permite que as pessoas, imediatamente após ouvirem sobre um novo lançamento, tenham uma noção aproximada de seu escopo. Quanto à compatibilidade com versões anteriores - idealmente _todos os lançamentos, mesmo os principais, são compatíveis com versões anteriores. E quando não puderem, porque uma API está mudando, isso deve ser feito de uma forma que não seja muito difícil de atualizar.

Mas evitar qualquer mudança na API e esperar que uma versão "PRINCIPAL" esteja pronta seria um grande impedimento para o progresso. E a alternativa de incrementar frequentemente o número da versão PRINCIPAL é incrivelmente inútil.

Honestamente, eu preferiria um esquema mais simples que usasse apenas BIG.SMALL números de versão - como a maioria dos aplicativos de desktop fazem ... mas eu me preocuparia com isso quebrando gerenciadores de pacotes e outras ferramentas.

Qual é o problema de estar no Backbone 43.0.0?

• Enviado do Chrome 32.0.1700

1 para spadgos @ question. Os números das versões são arbitrários. Por algum motivo, temos aplicativos da web ágeis tentando se manter dentro dos mesmos limites dos sistemas operacionais. Muitos aplicativos enlouquecem por passar de 10 ... mas a maioria dos projetos dos quais você está modelando (Windows, Linux, etc) tem ciclos de desenvolvimento de 1 ano / multi-anos antes do lançamento, então 1.x -> 2.x é um grande negócio. Um projeto ágil se move muito rapidamente, incrementar rapidamente também faz sentido.

Também discordo do raciocínio por trás disso.

Marionette está na v1.2.3 agora, e está fazendo o melhor para seguir o controle de versão semântico estrito. Até agora, não tivemos nenhum problema, embora também sejamos "todos superficiais". Adicionamos novos recursos. Corrigimos bugs. Mas v1.0 ainda é compatível com v1.2.3. Adiamos tíquetes para um lançamento v2 quando eles são API ou mudanças de quebra de comportamento esperadas.

As versões principais com alterações importantes não precisam acontecer todas as semanas quando uma solicitação pull é aceita. Eles podem (e devem) ser agrupados em uma versão principal que englobe valor suficiente para uma versão grande com um aumento na versão principal.

Do jeito que está, quebrar a compatibilidade em uma versão v1.1 causa muita dor para desenvolvedores de plug-ins e add-ons, como a equipe do MarionetteJS. Tivemos que preencher os comportamentos com patches em nosso código, para que possamos permanecer viáveis ​​para v1.0 e v1.1 ... não é uma situação divertida. Os efeitos em cascata de uma biblioteca central como o Backbone com alterações significativas são enormes ... não é apenas o Backbone que é afetado.

Concordo que isso parece mais um caso de "não quero" do que "não posso". Mudanças significativas, como https://github.com/jashkenas/backbone/pull/2461 , não têm um senso real de urgência e podem ter esperado por uma atualização de versão principal se você não quiser o problema 43.0.1.

Para mim, o maior problema do Backbone não respeitar semver (entre outras coisas) é ensinar e evangelizar o Backbone. Não é ótimo dizer a um grupo de alunos ou clientes em potencial que tudo em sua pilha vai funcionar de uma certa maneira ... exceto para o Backbone.

Sempre houve duas grandes advertências ao "evangelizar" o Backbone: não é AMD fora da caixa e não respeita a SemVer, portanto, não leve os números de versão a sério. Um deles é consertado. Vamos consertar o outro.

Honestamente, eu preferiria um esquema mais simples que usasse apenas números de versão do BIG.SMALL - como a maioria dos aplicativos de desktop fazem ... mas me preocuparia com isso quebrando os gerenciadores de pacotes e outras ferramentas.

@jashkenas, podemos sempre deixar o terceiro dígito em .0 :)

Isso provavelmente mapearia semanticamente para SemVer um pouco mais perto do que estamos fazendo agora. Talvez isso reprima algumas das críticas cripto-políticas passivo-agressivas sobre como é de alguma forma tecnicamente errado não seguir a SemVer.

Acho que o que Bob está dizendo está certo quanto ao fato de que é mais importante articular claramente qual sistema seguimos, independentemente de qual sistema seguimos.

ps Não quis dizer que o problema de @keithamus é passivo-agressivo e sinto muito se saiu dessa forma. Definitivamente, é legítimo discutir como o Backbone comunica as mudanças aos usuários.

: +1: para sempre. Estou interessado principalmente na versão de um determinado software, não como um índice de seu progresso, mas de sua compatibilidade.

Geralmente, depois da 1.0 (quando eu esperava que as coisas estivessem mais estáveis ​​e funcionando), os números de versão são amplamente insignificantes como indicadores de progresso. O software X na versão 10 pode ser muito menos maduro, ter menos recursos do que o software Y na versão 2. Se você quiser saber sobre o progresso de uma parte do software, deve olhar seu changelog ou roadmap.

Saber que o Backbone (ou qualquer outro) está em 2.4.3 não significa nada em termos de seus recursos. Isso _deve_, no entanto, significar que posso atualizar do meu 2.0.4 sem quebrar nada.

Se seguíssemos estritamente o controle de versão "semântico", provavelmente seria Backbone.js 43.0.0 agora - o que não ajuda ninguém a avaliar o progresso real do projeto.

Um problema muito pequeno / talvez inexistente. Não está seguindo semver? Grande problema.

: +1 :, semver é um must-have para um projeto tão grande.

Estou com @knowtheory. 43.0.0 parece um pouco estranho, mas acho que 1.43.0 estaria bem e ninguém teria uma quebra surpresa depois de npm install .

Quem se importa se os números de versão são altos?
É um padrão, se você pode usar, você deve usá-lo.
Eu nem entendo por que essa discussão está durando tanto.

: +1: Isso teria evitado alguns dos problemas em # 2996 e # 2997, e outros problemas tiveram com vários outros lançamentos de Backbone.

@braddunbar que (e o resto das razões "contra") parece que está valorizando a estética do número da versão em relação ao seu significado real.

Obrigado, mas seguir estritamente o versionamento "semântico" não funcionaria muito bem para o Backbone.

Acho que é mais sobre o Backbone funcionando bem para seus usuários (com gerenciamento de dependências). Qual semver seguinte garantiria ...

Versões mais freqüentes ajudariam a detectar bugs mais rápidos. Acho que é demais pedir às pessoas que executem constantemente versões edge do Backbone apenas para obter as correções de bugs de que precisam.

+1 @derickbailey

Apenas como um exemplo, desde 1.1.0, a ideia por trás dos lançamentos de patch é que essas correções não devem ser necessárias.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

Para pacotes em npm ou bower, isso nem é motivo de debate.

Quando você publica um pacote com npm ou bower, semver faz parte do contrato de API que você celebra. Quando você quebra esse contrato, você quebra outros módulos que dependem do seu. Você quebra o código de produção que depende do seu módulo.

A questão não é: "devemos usar semver?" A questão é: "queremos ser bons cidadãos no ecossistema?"

Se a resposta for não, isso deve ser anunciado em alto e bom som, porque não é seguro apenas instalar seu pacote como faria com qualquer outro pacote que segue o contrato de API.

Quando você publica um pacote com npm ou bower, semver faz parte do contrato de API que você celebra.

Não, não é. npm install --save [email protected] não é um requisito oneroso.

@ akre54 Estou interessado na sua perspectiva sobre o semver. Sei as opiniões de

@ akre54 Sim, é. O npm assume que todos os pacotes no repositório seguem sempre . É assim que ele determina quais pacotes são compatíveis com quais.

Do documento package.json :

"A versão deve ser analisada pelo node-semver, que é empacotado com o npm como uma dependência. (Npm install semver para usá-lo você mesmo.)"

Se seus números de versão _lie_ quando são interpretados como semver, essa não é uma análise correta. Portanto, você está quebrando o contrato package.json e está quebrando a compatibilidade com a forma como as pessoas usam as versões de pacote no ecossistema npm.

Não é apenas uma questão de preferência pessoal. É uma questão de interoperabilidade de pacotes.

É possível forçar seu pacote a jogar bem se ele não usa o semver? _Claro_, é, mas se você não falar em voz alta e ousadamente no topo do seu leia-me - poucos usuários saberão que é necessário e, quando você introduzir uma alteração importante, o código deles poderá facilmente quebrar.

Depois de publicar seus pacotes em repositórios de pacotes, o controle de versão se torna parte do contrato de interoperabilidade. Você ignora esse contrato por conta e risco de seus usuários.

npm install --save [email protected] não é um requisito oneroso.

Saber quais dos milhares de pacotes que entram em um aplicativo completo você tem que fazer isso _é_ um requisito oneroso. Forçar os usuários a bloquear totalmente as versões de todos os seus pacotes porque um punhado de módulos não seguem as regras _é_ um requisito oneroso, porque complica a questão de manter-se atualizado com correções de bugs, patches de segurança, etc ...

Existem boas razões para seguir sempre. "O número do meu pacote pode ficar muito grande" é uma razão terrível _não_ para usar o semver. Rastrear o progresso de seu aplicativo é um segundo motivo distante para versões de pacote. A função mais importante da versão é saber, "esta versão funcionará com meu aplicativo?"

Aliás, se o número do seu pacote ficar muito grande, talvez seja um cheiro de código. Você só precisa alterar a versão principal quando fizer uma _durta mudança_. Uma mudança abrupta, por definição, é aquela que _breaja o princípio aberto / fechado_. Aberto para extensão, fechado para alterações significativas. Todas as APIs boas seguem o princípio aberto / fechado o mais próximo possível, para que os usuários possam acompanhar o ritmo da API e as alterações não quebrem o código existente.

Acho que a lição aprendida aqui é "não use ~ ou ^ ao puxar no Backbone via package.json"

@ akre54 Estou interessado na sua perspectiva sobre o semver

Em geral, eu concordo com os argumentos aqui, mas tenho que me perguntar se empurrar a versão principal é o melhor curso de ação em _cada_ alteração de quebra (e novamente, com o sublinhado sendo principalmente a área de superfície, isso é _muito_). O sublinhado é usado em muitas bibliotecas de terceiros, e exigir que todos acompanhem as versões enormes seria oneroso e perigoso. (Um pacote lançado hoje deve depender do Underscore até a versão 2? 1.7? 1.6.x? Deve fixar suas dependências às custas de talvez exigir um Underscore separado do projeto principal?)

Acho que a lição aprendida aqui é "não use ~ ou ^ ao puxar no Backbone via package.json"

sim.

Acho que a lição aprendida aqui é "não use ~ ou ^ ao puxar no Backbone via package.json"

Descrevi acima por que essa não deve ser uma lição para viagem.

Acho que a lição aprendida aqui é "não use ~ ou ^ ao puxar no Backbone via package.json"

Isso é o que você faz, como consequência, para proteger o seu código de quebra.

A lição seria mais como "seguir sempre é bom para todos, não fazer isso não é."

Posso apreciar o valor do versionamento "romântico". Pena que eles não coexistem muito bem.

Deve-se notar que sempre haverá projetos que não seguem sempre à risca, e aqueles que tentam mas ficam aquém, então o sistema sempre vaza um pouco.

Pelo menos o Backbone é geralmente muito bom em não quebrar coisas.

@dgbeck as coisas quebram o tempo todo por versões, veja meu comentário anterior

Então eu acho que o valor de seguir o semver que não foi realmente falado é o fato de que vocês podem empurrar recursos menores e correções de bugs e permitir que as pessoas que dependem deles no upstream obtenham essas alterações gratuitamente.

Para mim, isso é um grande valor agregado, mas obviamente isso tem um custo de complexidade para o mantenedor.