On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch <vondruch@redhat.com> wrote:

Dne 21.11.2016 v 16:48 Chris Arcand napsal(a):
> This doesn't break semver.
> It does not introduce a backwards incompatible change from the Ruby ecosystem's perspective (the change is within internal specifications and is completely compatible with previous versions of Ruby/RubyGems). You're expecting a semver contract with internal gem specifications that doesn't exist.

For better or worse, there are more views then just "Ruby/Rubygems".

As a developer of rpms, you must also have things that are intentionally public and other things that are not intentionally public. There are always gray areas where "public API" is based on your perspective.

For anyone that doesn't consume gemspec contents line by line, that's clearly not public.  Since you do, you think it's public.

>> And what I am doing with the "gem spec" output is my business, I might just checking its checksum, or I might modify it, it doesn't really matter.
> Indeed, you can do whatever you want with the output. But note, there's further proof your semver contract isn't applicable here - from the RubyGems specification, `gem spec`'s purpose is described as follows:
>> The specification command allows you to extract the specification from a gem for **examination**.
> There's no break in contract, as you're still getting what RubyGems uses...for examination.

And "examination" means that the result of "gem spec" might be different
from version to version and can be freely changed?

Technically, they're ruby compatible.  Again, this is for examination so I would think it's not meant as a public API.
Not mentioning that this wording was introduced quite recently [1] and
from the commit, there is no obvious that it would be meant as "the
ouput is just informative, don't use it for anything".

You probably have been inspecting gemspec contents before 2013 but this change is over 3 years old and has shipped with ruby since ruby 2.1 so it's not quite recent.

Just for your information, we are modifying .gemspec files for as long
as I remember. This [2] is for example one of my first commit to
ActionPack and you'll see that we were modifying .gemspec files at that
time. May be it is not nice, but unfortunately, we have to do it.

Maybe we had to modify gemspecs in 2011.  Is it possible to summarize what we need to modify gemspecs for?
Since rubygems is telling us it's not a public API, even if we can't remove all of the gemspec modifications, it's probably best to try to remove the easier ones.

Note, we can continue to modify the gemspecs with the knowledge that any new rubygems version could break us.  That's a risk we can choose to accept.