He notado que en rubygems.org muchas de las gemas sugieren que las especifiques por versión principal en lugar de por versión exacta. Por ejemplo ...¿Debo especificar las versiones exactas en mi Gemfile?
gem "haml-rails", "~> 0.3.4" # "$ bundle install" will acquire the
# latest version before 1.0.
Sin embargo, en base a la Bundler docs sonaba a mí como que sería mejor para clavar la versión exacta como esto ...
gem "haml-rails", "0.3.4"
Así que está su gema haml-rails y todas sus dependencias no avanzarán. Si revisa el proyecto en una máquina diferente unas semanas más tarde y ejecuta $ bundle install
, tendrá exactamente las mismas versiones de todo lo que especificó.
He visto puntos de liberación de cosas, y pensé que parte de la idea de Bundler era "Bundle.lock
" todas sus versiones de gemas.
Pero en rubygems.org usan "~>" mucho así que tal vez me falta algo?
Cualquier aclaración sería muy útil para mí en la comprensión de la gestión de Bundler y la gema.
De acuerdo, las gemas se mantienen en sus versiones establecidas registradas en Gemfile.lock. Entonces, ¿cuál es el propósito de agregar "~>"? ¿Cómo es eso ventajoso? – Ethan
@ethan RubyGems tiene un [documento] (http://rubygems.rubyforge.org/rubygems-update/Gem/Version.html) que lo explica (ver la sección "Prevención de la catástrofe de la versión"). La esencia de esto es que solo permite que el último número entero en el número de versión aumente (por ejemplo, '~> 1.0.5' permite la actualización a la versión 1.0.9999, pero nunca a 1.1.x). El mecanismo es para permitir que las gemas se actualicen, pero sin introducir incompatibilidades que pueden romper las cosas (se supone que las gemas están siguiendo la política de "Rational Versioning" que vincula los contornos). –
@ethan Aquí hay un par de enlaces más en el sitio RubyDocs sobre el "[operador pesimista] (http://docs.rubygems.org/read/chapter/16#page74)" (~>) y [versiones racionales] (http : //docs.rubygems.org/read/chapter/7). –