https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112018-12-23T23:02:20ZRuby Issue Tracking SystemRuby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=758582018-12-23T23:02:20Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I was about to write a lot as a comment but I feel it just gets too long.</p>
<p>So a few comments - sorry for being short:</p>
<ul>
<li>
<p>You should not forget that management of gems (code in these gems) also<br>
takes time away from developers who maintain/keep ruby up to date.</p>
</li>
<li>
<p>Gems, or code, that is distributed with ruby itself, should be of higher<br>
priority than code hosted on rubygems.org or elsewhere. I disagree with<br>
any other way around e. g. where rubygems would be able to induce<br>
changes onto ruby. I mention this specifically because in several of<br>
these github issues, it feels to me as if people ignore or forget that and<br>
I think this is bad. Not just in the links you provide above, but I also saw<br>
prior discussions here about other gems.</p>
</li>
</ul>
<p>Ultimately I think the only thing that can be done here in the short term<br>
is to improve gems + rubygems.org.</p>
<ul>
<li>I agree with the consistency comment to some extent; in particular when<br>
gems in stdlib would break in major ways, that should probably lead to a<br>
situation where we could have multiple different versions, just as we have<br>
multiple different ruby versions. But this also brings us to the limitation of<br>
gems right now. We have only one name for a gem on rubygems.org (bundler<br>
allowed for more flexibility here with e. g. github-based projects); and<br>
we do not easily have multiple different versions available for different<br>
ruby versions or projects, in particular if some gems are pulled. That brings<br>
me back to the comment where I think gem + rubygems.org should be<br>
improved in the long run and provide more flexibility.</li>
</ul>
<p>I understand that this does not directly have that much to do with your<br>
issue about adopting a specific versioning scheme, but I think the<br>
versioning is actually a secondary issue, as long as we provide as much<br>
useful information as posible, while allowing users to use older gems too.<br>
But this also brings us back to changing gems so ...</p>
<ul>
<li>Last but not least, I think it may help what you specifically propose.</li>
</ul>
<p>For example:</p>
<p>"breaking change if and only if major versions bump"</p>
<p>This is a perfectly fine suggestion, for those users who may be affected.</p>
<p>But I, for example, also WANT to be able to use more up to date code<br>
and I don't mind breaking changes IF I can decide what to use and what<br>
not to use; so I would not agree to your statement if it means that it<br>
were to restrict me.</p>
<p>I am all in favour of heavily improving the whole gem ecosystem though;<br>
some of this may have to come from core ruby and matz may have to<br>
consider any changes there past 3.0. For example, "ownership" of<br>
"namespaces" - I don't mean this in the sense of restricting what others<br>
can do (I would be against this), but by providing meta-information<br>
about any change made on top of duck patching any ruby code too.<br>
But I digress. (On a side note, I do not version my gems, ironically enough,<br>
largely because I got tired of gem telling me about my own gems and<br>
own code that I could not easily install it - I always use the latest<br>
version of my own code and gems, so I could not accept gems restricting<br>
me here.)</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=758712018-12-24T12:57:19Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>You can understand Ruby versioning as some kind of rolling release.<br>
X.Y is decided with marketing consideration, though .Z is the same as Semantic Versioning's TEENY.<br>
see also <a href="https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/" class="external">https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/</a></p>
<p>Additional to say, I'm against the idea around X.Y of Semantic Versioning.<br>
Through my experience including both CRuby development and business,<br>
major version bump itself cause incompatibility in bundler ecosystems.</p>
<p>Moreover what you said in <a href="https://github.com/ruby/bigdecimal/issues/114" class="external">https://github.com/ruby/bigdecimal/issues/114</a> seems not<br>
API incompatibility defined in Semantic Versioning.<br>
Semantic Versioning says nothing about the application's dependency.</p>
<p>And you should propose suggestion with practical merit.<br>
These days many people specify versions in Gemfile like <code>gem "some-libs", "< 2"</code>.<br>
Bumping casually Semantic Versioning breaks such Gemfile and gems dependency.</p>
<p>You should also check why we need to downgrade bundler to 1.17 and released RC2.<br>
<a href="https://github.com/rubygems/rubygems/pull/2515" class="external">https://github.com/rubygems/rubygems/pull/2515</a><br>
You need to learn how bumping major version cause problems before enforcing major version bump.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=758722018-12-24T15:35:11ZJonRowe (Jon Rowe)hello@jonrowe.co.uk
<ul></ul><blockquote>
<p>These days many people specify versions in Gemfile like gem "some-libs", "< 2".<br>
Bumping casually Semantic Versioning breaks such Gemfile and gems dependency.</p>
</blockquote>
<p>More people use <code>gem "some-libs", "~> 2.0.0"</code> and having breaking changes in a minor or patch release break the applications dependant on them.</p>
<p>This the typical style for web apps because it makes security updates easy to apply without changing a Gemfile / gemspec.</p>
<p>The whole point of a major version bump is stop both of these styles from accidentally picking up a breaking change.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=758732018-12-24T21:42:12Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p>Just for a point of reference, I use "~> x.y" for all my dependencies, as, taking into consideration semantic versioning, this allows for the maximum range of support but excluding breaking changes (i.e. x must stay the same, but y can increase).</p>
<p>This is all really good discussion, let's keep the ideas flowing.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=759152018-12-27T00:09:46Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><blockquote>
<p>Just for a point of reference, I use "~> x.y" for all my dependencies, as, taking into consideration semantic versioning, this allows for the maximum range of support but excluding breaking changes (i.e. x must stay the same, but y can increase).</p>
</blockquote>
<p>Yeah, as <code>lib/rubygems/version.rb</code> says people should use "~> x.y" to avoid breaking changes if you are pessimistic.</p>
<pre><code># Specification From ... To (exclusive)
# ">= 3.0" 3.0 ... &infin;
# "~> 3.0" 3.0 ... 4.0
# "~> 3.0.0" 3.0.0 ... 3.1
# "~> 3.5" 3.5 ... 4.0
# "~> 3.5.0" 3.5.0 ... 3.6
# "~> 3" 3.0 ... 4.0
</code></pre>
<p>But dropping old rubies will happen every year and it can affect gems to remove legacy code.<br>
If it is considered as breaking changes as you said, it will cause major bump and it's false positive for normal users who runs application with current rubies.</p>
<p>I think such false positive hearts Semantic Versioning.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=759162018-12-27T00:17:01Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><blockquote>
<p>But dropping old rubies will happen every year and it can affect gems to remove legacy code. If it is considered as breaking changes as you said, it will cause major bump and it's false positive for normal users who runs application with current rubies.</p>
</blockquote>
<p>I'm sorry, but I don't understand how this is a problem. Can you explain it in more detail with an example?</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=761842019-01-10T07:19:35Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>ioquatix (Samuel Williams) wrote:</p>
<blockquote>
<blockquote>
<p>But dropping old rubies will happen every year and it can affect gems to remove legacy code. If it is considered as breaking changes as you said, it will cause major bump and it's false positive for normal users who runs application with current rubies.</p>
</blockquote>
<p>I'm sorry, but I don't understand how this is a problem. Can you explain it in more detail with an example?</p>
</blockquote>
<p>Mr.A create a1.gem and its version is 1.0 which support Ruby 2.0, 2.1, and 2.2.<br>
Mr.B write an application which uses a1.gem and write in <code>gem "a1", "~> 1.0"</code> Gemfile.</p>
<p>Next year, Mr.A drops Ruby 2.0 support and released a1.gem as 2.0.<br>
Mr.B update Gemfile as <code>gem "a1", "~> 2.0"</code>.</p>
<p>Next year, Mr.A drops Ruby 2.1 support and released a1.gem as 3.0.<br>
Mr.B update Gemfile as <code>gem "a1", "~> 3.0"</code>.</p>
<p>Next year, Mr.A drops Ruby 2.2 support and released a1.gem as 4.0.<br>
Mr.B update Gemfile as <code>gem "a1", "~> 4.0"</code>.</p>
<p>Next year, Mr.A drops Ruby 2.3 support and released a1.gem as 5.0.<br>
Mr.B update Gemfile as <code>gem "a1", "~> 5.0"</code>.</p>
<p>This is yearly normal changes is syntactically equal to big bang change.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=765292019-01-26T11:05:06Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p>My understanding of semantic versioning is that what you depend on is not part of your public API. So, if you drop versions of Ruby, you can release new minor version, it's good enough.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=765382019-01-26T22:05:45ZEregon (Benoit Daloze)
<ul></ul><p>Just one example where a popular gem was basically forced to keep compatibility with older versions, or needs a major version increase:<br>
<a href="https://github.com/ruby-concurrency/concurrent-ruby/issues/768" class="external">https://github.com/ruby-concurrency/concurrent-ruby/issues/768</a></p>
<p>I'd guess there are many other similar cases.<br>
One concern there is gems depending on the gem removing compatibility are forced to drop compatibility for that Ruby version too, or have very strict version constraints (such as == last_working_version).</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=765392019-01-26T23:25:45ZMSP-Greg (Greg L)
<ul></ul><p>I'm confused. I'll use major.minor.teeny</p>
<blockquote>
<p>Next year, Mr.A drops Ruby 2.0 support and released a1.gem as 2.0.<br>
Mr.B update Gemfile as gem "a1", "~> 2.0".</p>
</blockquote>
<blockquote>
<p>Next year, Mr.A drops Ruby 2.1 support and released a1.gem as 3.0.<br>
Mr.B update Gemfile as gem "a1", "~> 3.0".</p>
</blockquote>
<p>No mention as to whether the releases contain breaking API changes. If not, why a new 'major' release, vs a 'minor' release?</p>
<p>Or, if the only change is dropping compatibility with a Ruby version, why is a new major release required?</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=765422019-01-26T23:43:59ZMSP-Greg (Greg L)
<ul></ul><p>Ok, maybe I'm not confused.</p>
<p>Assume gem a-1.8 exists with a lower Ruby version constraint of >= 2.0, and a-1.9 exists with a lower Ruby version constraint of >= 2.2.</p>
<p>If one has pessimistic versioning of major.minor, RubyGems will select 1.9, but won't be able to install it on Ruby 2.0.</p>
<p>This is due to the fact that RubyGems improperly handles Ruby version constraints. IMO, this issue discourages the use of newer Ruby versions and also newer gem versions. It should be fixed, and it should be added to new releases of both RubyGems 2.x and 3.x.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=767302019-02-07T10:51:40Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a> If users are on 1.9.3, and the gem 1.0.5 supported it, and 1.1.0 didn't, I think you can argue that (a) it violates semantic versioning because a minor version bump broke the build but you could also argue that (b) it's compatible with semantic versioning because the ruby dependency is an internal detail to the gem (at least from it's own POV).</p>
<p>That being said, users who say <code>gem 'concurrent-ruby', '~> 1.0'</code> should correctly receive the latest compatible gem which suits their Ruby version, and that seems fine to me. The fact it's not being selected correctly might be a bug as <a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11129">@MSP-Greg (Greg L)</a> seems to be pointing out?</p>
<p>Looking at the bigger picture, I see that there are two cases, highlighted by the linked issue: pain for old users, or pain for up to date users. Honestly, I don't care so much about users of old releases. I do believe it should keep working, but I'm more concerned with breaking users who are using the latest stable release. <code>¯\_(ツ)_/¯</code> - so I think it was a mistake for <code>concurrent-ruby</code> to yank the <code>1.1.0</code> release, that caused real issues with production deployments.</p> Ruby master - Feature #15456: Adopt some kind of consistent versioning mechanismhttps://redmine.ruby-lang.org/issues/15456?journal_id=767352019-02-07T18:26:17ZEregon (Benoit Daloze)
<ul></ul><p>ioquatix (Samuel Williams) wrote:</p>
<blockquote>
<p>so I think it was a mistake for <code>concurrent-ruby</code> to yank the <code>1.1.0</code> release, that caused real issues with production deployments.</p>
</blockquote>
<p>Right, especially since nowadays <code>gem yank</code> even deletes the file on the RubyGems server, instead of just skipping the version for Bundler resolution.</p>
<p>But it does mean to drop 1.9 support, concurrent-ruby can only do so with a 2.0 release to keep '~> 1' users happy.</p>
<p>MSP-Greg (Greg L) wrote:</p>
<blockquote>
<p>Assume gem a-1.8 exists with a lower Ruby version constraint of >= 2.0, and a-1.9 exists with a lower Ruby version constraint of >= 2.2.</p>
<p>If one has pessimistic versioning of major.minor, RubyGems will select 1.9, but won't be able to install it on Ruby 2.0.</p>
<p>This is due to the fact that RubyGems improperly handles Ruby version constraints. IMO, this issue discourages the use of newer Ruby versions and also newer gem versions. It should be fixed, and it should be added to new releases of both RubyGems 2.x and 3.x.</p>
</blockquote>
<p>Do you mean that the ruby version constraint of the gems should be taken into account for version resolution, and currently it's not at all?</p>
<p>This seems an interesting path forward: only consider versions of a gem which are compatible with the Ruby version running RubyGems or Bundler (or <code>ruby "2.x.y"</code> in the Gemfile).</p>