I have built my first ruby app there: https://rubygems.org/gems/youtube_dlhelper. As shown in Versions the correct versions are available: 0.1.0, 0.1.1 and 0.1.2.
But it looks like rubygems lists just the oldest 0.1.0.
Maybe anyone knows why?
The latest version of your gem is not showing up as the default because it does not conform to the Semantic Versioning specifications. Although it may seem obvious to us as humans that 0.1.2.alpha is greater than 0.1.0.alpha, a quick look at the spec shows that this is the incorrect way to specify a pre-release. Here's a relevant excerpt (emphasis added by me):
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
I'm not exactly sure how 0.1.2.alpha is being interpreted, but I think your best bet is to release a 0.1.3 version of your gem and yank the incorrectly versioned ones. You may even try releasing a 0.1.3-alpha, but I'd wait until someone more knowledgable can a give a more definitive answer.
In the meantime, I'd definitely encourage you to look at the Semantic Versioning specs.
Related
I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?
If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?
I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?
If a gem worked with ruby 2.3.0, is it true that it will definitely
work with 2.5.1
This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.
In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.
Gem is simply a plug-in library written in Ruby.
Of course, Ruby is developing, new features are appearing, old ones are disappearing.
It's best practice to specify Ruby version in .gemspec file. For example, like this one.
But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.
For automation, of course, it is best to use tests.
Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.
Should any gem happen to use an API that changes, an incompatibility will arise.
The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.
A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.
Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)
My question is about the ruby-doc.org documentation, but also relates to the ri documentation lookup inside ruby.
I've already read dozens of similar questions/answers about the ri not working and giving "nothing known" messages and I've tried to follow some of that old advice. It just seems that those old answers aren't applicable to me.
One was to install the rdoc --all --ri from the ruby root directory. I tried that and it failed (unable to convert to UTF8 or something like that).
Another suggested that the rubyinstaller for windows installer just doesn't contain that info anymore and I should use the online documentation, which, when I goto http://ruby-doc.org/downloads/ I discover that the version I am using (2.4.4) does not exist.
This is odd, because the rubyinstaller site specifically says that if I'm new to Ruby(which I am), I should install 2.4.4. You'd think that if any version had good documentation, it would be that one. Instead, it seems to be missing entirely.
This all started because I am trying to learn Ruby and am watching the Lynda.com course on Ruby by Kevin Skoglund, which was recorded many versions ago and in that course he refers to the ri command from the shell, which in my version doesn't work. see below:
ruby --version
ruby 2.4.4p296 (2018-03-28 revision 63013) [x64-mingw32]
ri --version
ri.cmd 5.0.0
ri String
Nothing known about String
Now, if it's not available within ruby using ri, and I have to use online documentation, AND it's missing for my version, which happens to be the version recommended for new users, … you see my frustration.
Here's what I really want...
1. I want to use ri and have it work.
2. If that's just not possible, I'd like to know where the documentation for my version is online, because it's not where it's supposed to be.
Any help is appreciated. If it involves installing anything, letting me know HOW to do that is also appreciated. As I mentioned, I'm new.
Since you are using the RubyInstaller, I will assume that you are on Windows.
I will open this by saying that I am not 100% on this, but I am pretty condfident in this answer.
The "Use 2.4, not 2.5" was due to errors with Ruby Gem when Ruby 2.5
was first released, as I happen to be on a Windows machine installing
Ruby at that exact time, and that was the reasoning at that point not
to use the newest 2.5 version.
The above mentioned reason has since been corrected.
Realistically, if you are beginner, as long as you using documentation that is close to your version (2.0+ - 2.4-ish), it will be fine. Now obviously, and I shouldn't have to provide this disclaimer, though I will so to avoid the inevitable down-votes if I don't, this is not 100% perfect solution and there will be very small differences. As a beginner, the likelihood of you encountering any of these differences are extremely low, low enough not to even worry about. There are missing and poorly documented sections of every language, and Ruby is no exception. Typically these are less used classes (though Ruby Fiddle is an exception that I hate how poorly documented it is), and will have no effect on your learning process as you learn the fundamentals and core of the language.
To my recollection, the "core" is rather well documented, and so long as you use documentation from 2.0+ (the closer to 2.4 the better), you should be completely fine, and it is exactly the same. The "standard library" may be slightly more hit or miss, and your mileage may vary a little more, yet still nothing too extreme.
So, to address the second part of your question, do not worry too hard about finding the EXACT version of documentation you are using. It may not even exist online, though the installer should have provided a CHM help file (there will be shortcut for it with the shortcuts for Ruby, IRB, etc.
As for "why" ri is not working, I am not 100% sure yet again. I am on ArchLinux, and RDoc doesn't even built. Honestly, RDoc is being left by the wayside for newer (and IMO better) document engine, namely YARD. A possible solution that I do, and prefer, is to install the YARD gem right after I install Ruby:
gem install yard
And then set YARD to generate my documentation with this in CMD:
yard config --gem-install-yri
If you decide to take this route, much more can be learned about it here.
The benefit with it is that it also supports RDoc and is backwards compatible.
I am creating a gem and I have the suspicion that it may not work on certain Ruby versions. Is there a way to quickly check which Ruby versions it is compatible with? My current method is using RVM and switching to different Ruby versions to test, but that may be an inefficient way to do it. I was also wondering if I could narrow it down to a specific patch version.
#Matt Schuchard suggested the right way to do this (in the comment)
For example, you can check how to do this with GitHub Actions. You can test it not only for specific ruby version but also on different OSes
https://github.com/metanorma/metanorma/blob/master/.github/workflows/rake.yml
I would like to know, if e.g. 0.1.0 is already stable concerning a composer install.
I am familar with the SemVer Tags and I know, that the API can change with every realease which is not the first major (1.0.0) but still: the tag is a fixed state of the project.
So, will composer consider such a tag as stable or not?
From a semantic versioning perspective, it is not stable. However, Composer will treat (almost) all tags as having stability "stable".
Good to know: the ^ operator behaves very similarly to the ~ operator but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.
For more information, see https://getcomposer.org/doc/articles/versions.md
I have a gem published here: https://rubygems.org/gems/rangy-rails/
When I first released it in March 2013 I later realized that I had set an incorrect version.
I immediately yanked the gem and resubmitted it with the correct version. Unfortunately RubyGems does not remove the yanked gem and this is causing two problems:
The version list is not ordered correctly (yanked gem is on top): https://rubygems.org/gems/rangy-rails/versions
My gem's main page on RubyGems: https://rubygems.org/gems/rangy-rails/ is using a description about the gem being yanked instead of the gemspec's description.
How can I fix this?
So far my only option seems to be contacting RubyGems but they explicitly say the following:
Our policy is to only perma-delete gems that really need it, such as
gems that may contain passwords, malicious/harmful code, etc. Yanking
a gem effectively removes it from being found and will do the trick in
99% percent of situations.
(source: http://help.rubygems.org/kb/gemcutter/removing-a-published-rubygem)
Problem 2 is solvable. The description is taken from the latest non-prerelease version of the gem (not including yanked versions). (See more info about prerelease gem versions here.) Right now, your gem has 3 versions, and the two non-yanked ones are both prerelease (they have letters in the gem version). If you push a new version of the gem, even if it's 0.0.1 or something, that's a "release" version, and it will be used for the description instead.
I made a little test gem here to demonstrate what I'm talking about -- notice that the description page is taken from the latest non-prerelease version (0.0.1, in my case.)
There is no self-serve way to "solve" problem 1 -- Rubygems.org will always display your gem versions in semantic versioning order, from highest to lowest. I'm not sure why this is a big issue, though -- most people typically won't look at the versions page. Yanking will mask the bad version in most situations and, as the documentation says, will probably "do the trick" in this case.
If you really want to permanently hide the traces of the yanked gem and remove it from the versions list completely, you'll need to contact the Rubygems staff and see if they're willing to help out.
You need to publish new version, that is more than yanked. I.e., if yanked version is 1.3.0.772, you need to publish 1.3.0.780 (for example)