gem "awesomesauce", "~> 1.2.3"
Você está copiando cegamente a ~> x.y.z
restrição para o seu .gemspec
, não é? Você devia se envergonhar!
Você deve se restringir a ~> x.y
.
Espere porque?
Porque as pessoas que usam sua gema estão cansadas de ver isso :
Bundler could not find compatible versions for gem "awesomesauce":
In Gemfile:
gemmit depends on
awesomesauce (~> 2.1.0)
fuzzin depends on
awesomesauce (~> 2.2.0)
Antes de prosseguir, aqui está um glossário rápido e uma atualização:
~> xyz
~> 1.2
é uma abreviatura para>= 1.2.0
,< 2.0.0
~> 1.2.3
é uma abreviatura para>= 1.2.3
,< 1.3.0
Versão semântica
Um número suficiente de joias aderem ao versionamento semântico para que possamos assumir que é o caso. Se não o fizerem, devemos dar-lhes uma merda para não!
Quando uma gema ultrapassa a versão xy Z : as únicas mudanças são (normalmente) correções de bugs.
Quando uma gema bate no x. Y .z versão: novos recursos são adicionados, mas os recursos existentes são não quebrado.
Quando uma jóia bate o X versão .yz: para trás mudanças incompatÃveis foram introduzidas.
Explique, já!
No exemplo acima, gemmit
está expressando que deseja que a funcionalidade seja lançada na versão do . Da mesma forma, precisa da funcionalidade introduzida em .2.1.0
awesomesauce
fuzzin
2.2.0
Em virtude do controle de versão semântico, podemos estar razoavelmente seguros de que a versão de não quebra a funcionalidade de sua versão. Então, por que está restringindo ?2.2.0
awesomesauce
2.1.0
gemmit
< 2.2.0
Porque o autor não pensa em seus usuários.
E agora você está preso a versões antigas de gemas que não quer ou é forçado a corrigir o gemspec para liberar suas restrições. Ugh.
Para um mundo sem dor, tudo o que precisamos é:
gem.add_dependency "awesomesauce", "~> 2.1"
Sim, mas e se eu precisar depender de uma versão Z?
Então, depende disso! Nada o impede de expressar requisitos de versão mais complexos:
gem.add_dependency "awesomesauce", "~> 2.1", ">= 2.1.3"
O mundo agradece por você fazer isso.