Found this related post, https://stackoverflow.com/questions/7139/should-a-first-release-be-an-0-1-version-or-1-0b, but it is not about Ruby Gems. I am asking about the best and common practice for Ruby Gems.
I'll start with 0.0.1, and probably get to 0.0.10 when it is fully tested and ready for use.
Does it make sense to leave the version at 0.x.x? Or does that mean that the gem is beta and not stable and not ready for use? Is it better to set the version to 1.0.0?
Hosting on RubyGems and GitHub.
Thanks to matt, the docs at semver.org say that yes, release software should be at least v1.0.
Related
When authoring a gem, what would be reccomended practice for version restrictions of dependencies. For example I know that know that my gem works wih rubyzip version 2.x, but I also know that it works for 1.9 as well. Should I state
spec.add_runtime_dependency 'rubyzip', '>1.8'
or if the rubyzip version 1.9 is long time outdated, it is more common to "push" change for 2.x line? Also if I use the mentioned line, that I risk incompability with future versions, but on the other hand, leave the coice to the user.
Note: the questions is generall and dependency on rubyzip is just an example.
If you know that your gem works with rubyzip 1.9, then there's really no need to force people to use >=2.0 with it.
Sure, updating dependencies would be a good idea for your library-user to do, but it's not your job to be the "update-your-software-police"!
Specifying that the version must be < 3 is generally advisable (although not consistently done by developers), as there's a reasonable risk that a major dependency version bump will be incompatible with this version of your code.
So, as a compromise, you could do:
spec.add_runtime_dependency 'rubyzip', '>=1.9', '<3'
See the documentation for valid syntax examples.
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? :)
DISCLOSURE: I know very little about Ruby beyond some basic code syntax. Bear with my idiocy.
Ruby 1.8's OpenSSL library doesn't seem to support TLS 1.2. However, there are apps running that are dependent on 1.8, so I want to see if I can run a newer version of Ruby concurrently on the same system and get it set up with newer versions of the same gems.
Currently version 1.8 is at /usr/lib/ruby/1.8. Ideally, I'd like to keep the same structure and install a newer version (not sure what the most recent, stable version is - whether it's 2.3.x or 2.4.x).
That said, I am not a Ruby admin. I inherited a server from someone else who decided Ruby was the best way to do things, despite there being no other Ruby experience within the company, and then they left. I know some system admin stuff, but I don't know:
How backwards-compatible Ruby versions are (e.g. would an app built against 1.8 run without any major modifications on 2.4.1).
How gems work / get updated. Can 2.4.1 use gems from 1.8, or are gems tied to specific Ruby versions? Can there be a mix-and-match? Is there a migration path of some kind?
How to properly manage two different concurrent versions (how to tell an app to use one version over the other, or prevent existing apps from automatically trying to use the new version and breaking if they're not compatible).
Any best install practices (I usually compile from source, but am open to suggestions).
Is it even possible to just update Ruby's OpenSSL library without updating the whole Ruby app? It's currently on OpenSSL 0.9.8o, so it's pretty significantly behind the times.
The server is running Debian 6.0.6 (I'm more familiar with Red Hat and CentOS, though, so any hints on package management, etc... related to this issue would be welcomed).
Modern ruby has "matured" and become very stable. Upgrading from 2.0.0 --> (the latest stable) 2.4.1 is generally quite easy. However, ruby went through a period of fairly major (necessary!) changes from 1.8 --> 1.9 --> 2.0; this part of the upgrade may be problematic.
Gems are installed within the current ruby installation. So for example, you currently have the "ruby 1.8 version" of CanCan. If you update the ruby version of this application, you will need to re-install all gems (presumably via bundle install) for the ruby version. The migration path is basically: Get as comprehensive a test suite as possible; upgrade gems as much as possible within that ruby version; update the ruby version; fix tests and/or code if necessary; repeat.
Use a tool like rvm or rbenv to install multiple concurrent ruby versions on one machine.
See point 3. You probably don't need to compile anything from source.
Ruby 1.8 is old. Support for it was dropped back in 2013. Your application will undoubtedly have a huge list of outdated libraries now, with all sorts of security vulnerabilities -- that's what happens when you don't update it for 6+ years! From a security standpoint, I would not suggest trying to find some workaround for this one OpenSSL issue and ignore the larger problem here.
I'm using rvm on Ubuntu 12 to manage ruby versions/gemsets. I am testing various projects and some gems won't work with certain versions of Ruby or with each other. Is it possible to find which version of ruby an app was written for, so I can set my rvm to use that version and get the right gems when I run bundle install?
You can lookup the gems on rubygems.org. They are supposed to list what version of ruby they are compatible with, but that may not always be kept up to date.
If that doesn't narrow it down, you can check the gem's CHANGELOG file on github.
In the end, you may have to just try a few. There's only a handful of versions in common use, so it's not like you have to try then all.
in my experience ruby 1.9.3 is most widely supported at the time of this writing. Ruby 2.0 and 2.1 would also be good to try. 1.8.7 is pretty old and will likely give you a good bit of trouble, but it was the standard for a long time.
It seems like there are no guidelines on Ruby Gem package submission. There's no way to tell what is the definitive package for your needs. At least not within the Gem framework itself. Or am I missing something?
For example: I found out about "ActiveLDAP". I did
gem search ldap --remote
and got back
*** REMOTE GEMS ***
activeldap (1.0.2)
ambitious-activeldap (0.1.1)
ruby-activeldap (0.8.3.1)
ruby-activeldap-debug (0.7.4)
I ended up installing 'activeldap' and 'ruby-activeldap'. Turns out they're the same package: "ruby-activeldap" is just an older version.
Is there a way within the Gems framework to differentiate them, without having to Google for the answer. A short doc string, for example, or a dependency tree?
Seems like there are lots of these type of discrepancies in Gems.
If you are installing the gem because of a dependency in a script, you might be able to tell based on:
require_gem 'rake', '>=0.7.0', '<0.9.0'
Other than that, I am not sure either to be completely honest. I would usually go with the latest version of something in cases where a require does not specify which one is needed.
[edit]
I would use the one that appears to be the most mature first (1.0 over 0.X).
[/edit]
I think you could look around and find guidelines, but whether or not they're followed is an entirely different matter!
This is open source software - it costs you nothing to buy, but I'm afraid you're going to have to invest some time to determine if a package does what you want.
It's relatively straightforward to determine how recently a gem has been released and how many times and with what frequency updates have occurred. These are indicators that the source is being actively maintained and that effort is going into its continuing relevance. You can also look at tests (usually installed with the package), existence of bug tracking facilities, discussion groups or forums and the like in order to assess the degree of commitment from the developer(s) and the amount of penetration and community around the code.
Beyond that, what were you hoping for? Value for money? Some central authority that accredits the fitness for purpose of a library? It ain't going to happen any time soon, and that's probably, on balance, no bad thing.
You can get more detail in your search results that might help you narrow it down if you use the details and all options:
gem search activeldap --remote --details --all
all shows the list of versions.
Part of the output:
activeldap (1.0.2, 1.0.1, 1.0.0, 0.10.0, 0.9.0)
Authors: Will Drewry, Kouhei Sutou
Rubyforge: http://rubyforge.org/projects/ruby-activeldap
Homepage: http://rubyforge.org/projects/ruby-activeldap/
Ruby/ActiveLdap is a object-oriented API to LDAP
ambitious-activeldap (0.1.1, 0.1.0)
Author: Matthew King
Rubyforge: http://rubyforge.org/projects/ambition
Homepage: http://ambition.rubyforge.org/
An ambitious adapter for ActiveLDAP
Beyond that, as Mike said, it's sort of a matter of poking around on the Web to try to suss out what's the most relevant version.
One thing to note: wholesale migration around mid 2007 in the Ruby/Rails communities to Github. So if you find something but it's not on Github, make sure it's not some old version that's been superseded.