Issue #15456 has been updated by shevegen (Robert A. Heiler).


I was about to write a lot as a comment but I feel it just gets too long.

So a few comments - sorry for being short:

- You should not forget that management of gems (code in these gems) also
takes time away from developers who maintain/keep ruby up to date.

- Gems, or code, that is distributed with ruby itself, should be of higher 
priority than code hosted on rubygems.org or elsewhere. I disagree with
any other way around e. g. where rubygems would be able to induce
changes onto ruby. I mention this specifically because in several of
these github issues, it feels to me as if people ignore or forget that and
I think this is bad. Not just in the links you provide above, but I also saw
prior discussions here about other gems.

Ultimately I think the only thing that can be done here in the short term
is to improve gems + rubygems.org. 

- I agree with the consistency comment to some extent; in particular when
gems in stdlib would break in major ways, that should probably lead to a
situation where we could have multiple different versions, just as we have
multiple different ruby versions. But this also brings us to the limitation of
gems right now. We have only one name for a gem on rubygems.org (bundler
allowed for more flexibility here with e. g. github-based projects); and
we do not easily have multiple different versions available for different
ruby versions or projects, in particular if some gems are pulled. That brings
me back to the comment where I think gem + rubygems.org should be
improved in the long run and provide more flexibility.

I understand that this does not directly have that much to do with your 
issue about adopting a specific versioning scheme, but I think the 
versioning is actually a secondary issue, as long as we provide as much
useful information as posible, while allowing users to use older gems too.
But this also brings us back to changing gems so ...

- Last but not least, I think it may help what you specifically propose.

For example:

"breaking change if and only if major versions bump"

This is a perfectly fine suggestion, for those users who may be affected.

But I, for example, also WANT to be able to use more up to date code
and I don't mind breaking changes IF I can decide what to use and what
not to use; so I would not agree to your statement if it means that it
were to restrict me.

I am all in favour of heavily improving the whole gem ecosystem though;
some of this may have to come from core ruby and matz may have to 
consider any changes there past 3.0. For example, "ownership" of 
"namespaces" - I don't mean this in the sense of restricting what others
can do (I would be against this), but by providing meta-information 
about any change made on top of duck patching any ruby code too.
But I digress. (On a side note, I do not version my gems, ironically enough,
largely because I got tired of gem telling me about my own gems and
own code that I could not easily install it - I always use the latest 
version of my own code and gems, so I could not accept gems restricting
me here.)

----------------------------------------
Feature #15456: Adopt some kind of consistent versioning mechanism
https://bugs.ruby-lang.org/issues/15456#change-75858

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
After the discussion https://github.com/ruby/bigdecimal/issues/114 I feel like we would benefit from some consistent versioning mechanism across all of Ruby.

So far, I feel the majority of Ruby uses some form of semantic versioning.

For the sanity of all Ruby users, I think it would be a good policy to adopt this across core Ruby and standard gems.

There are some previous discussions around this:

- https://bugs.ruby-lang.org/issues/9215
- https://bugs.ruby-lang.org/projects/ruby/wiki/GeneralMaintenancePolicy
- https://bugs.ruby-lang.org/issues/8835

So, the questions are as follows:

- Can we adopt Semantic Versioning (or as much of it as possible) across Ruby?
- Would such a change help users of Ruby?
- Is there existing documentation about how version number works?
- How does it deviate from Semantic Versioning?
- Is this deviation important and worth the additional complexity for our users?

As an aside:

- How do other implementations advertise compatibility with Ruby?
- JRuby and RBX have totally different version numbers that are difficult to understand w.r.t. compatibility with mainline CRuby.

My main concern is how difficult this is for everyone to keep track of and also the implied assumptions (e.g. breaking change if and only if major versions bump). If different parts of Ruby use different versioning scheme, it is hard for our users to define dependencies which don't cause broken software.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>