Assume we've got a gem. (e.g: gem 'bcrypt', '~> 3.1.7')
I wanna update it to the latest version of that. but I don't know what is the difference between these two versions. actually, I wanna know, what is the difference between these two versions? what is the difference between syntaxes in these two versions?
so, How to compare gems versions?
what is the difference between syntaxes in these two versions?
This part of the answer is easy: Ruby does not allow programmers to change the syntax, so a gem cannot possibly change the syntax, ever.
When the source code of a gem is managed in a public code repository, like GitHub or Gitlab, then you will often find a CHNAGELOG on these repositories. Such a changelog is written manually by the maintainers and might not be complete but it gives you a good overview of what has changed and what the maintainers think is important to know.
Another way to compare two versions is to compare the code of the two versions. Because the code of the bcrypt is public and the maintainers added tags on GitHub for each version this is very easy. Go to the page listing all releases and compare one release to another by choosing two versions. For example 3.1.13 (the lastest) to 3.1.7 (the minimum version from your Gemfile). The following page allows you to see all commits and all changed files between these two versions.
First check that do you really want to update the gem? This means if your running code break due to your old version of a gem then there must be new changes that would be solved your problem. (which are the difference ;) )
Second - what is the difference between these two versions or how to compare?
1. rubygem.org
If you check the rubygem.org site and fetch any gem, then at the right bottom side there should be a 'Review Changes' link that shows the changes done during version change.
2. Gem repo
You can also check the 'CHANGELOG' or 'README.md' files in the gem repository that contains the information regarding version changes or comparison (if the author is updating it).
3. Ruby Gem
There is a gem 'gem-compare' which shows the information of versions changes.
Most projects publish a changelog or a list of releases. They can usually be found on the repo or on their website. They often link specific PR’s included in each release and specify if a change was “breaking” (although the version itself should communicate if it’s a major, minor, or patch update). To compare your current version to latest, you would start at the version you’re on and review all the versions released since then.
Here’s bcrypt’s release log, for example:
https://github.com/bcrypt-ruby/bcrypt-ruby/releases
Related
I love OSS contribution but trying to get involved into OSS contribution. Recent I give a try to rails 4.2.4.rc1 with rails 4.2.3 and got failure for testcases.
The app works perfectly with rails4.2.3 and in the latest release candidate it's throwing some errors. I'm trying to figure out the issue.
could anyone help me to find the change from 4.2.3 version to 4.2.4.rc1 in main rails repository? I feel that will help me to resolve the bug.
How I can find the difference from github.
Note: changeLog only contains the error message not the commit details.
I am not sure that I grasp your question.
You are speaking about tests from rails but also about an app that works.
If you want to try different rails versions for your app, I would use rvm and gemsets. Official documentation, but you will find imho nicer tutorials about that elsewehere. Actually, I would always use rvm and gemsets :) .
Changes between two versions can be seen on the github webpages, e.g. for rails - coming from the small green two-arrow-button to create pull-requests. Or you do it on the commandline git help diff, plus there are various graphical tools which I rarely resort to use (I am happy with gitk but there are probably fancier alternatives).
So I upgraded to 1.4 for a project I am contributing to (in development/testing branch of course) and ran into some problems and thus we want to use Dart 1.3.6 again. However, I cannot find this.
Does anyone know where I could download it?
I have seen and starred https://code.google.com/p/dart/issues/detail?id=18323
as I was putting this question together, but of course seems like there is no more movement there just yet.
I think I pretty much ran into similar issues to what corgath described in comments on this question... looking for the right version in those "archives" where the "latest" is not really the latest anymore.
Update
There is now a nice page to select and download specific Dart versions https://www.dartlang.org/tools/download-archive/
Since a while there are also deb packages available which can be installed using
sudo apt-get install dart=1.7.0-dev.0.1.*
see https://www.dartlang.org/tools/debian.html for more details.
Original
You can download from
http://gsdview.appspot.com/dart-archive/channels/stable/release/
The list only contains the build number but each folder contains a file VERSION that contains detailed version information for this build.
dev channel releases can be found here
http://gsdview.appspot.com/dart-archive/channels/dev/release/
there are also unsigned raw builds (bleeding edge) but it is not recommended to use them.
http://gsdview.appspot.com/dart-archive/channels/be/raw/release/
Till now, I just use the gem name and avoid mentioning the version number, is this a good practice (pros: the gems keeps on getting updated automatically, cons: the app can break)
if it is a good idea to use version number, what are the standard practices to use it ?
EDIT - I just did "bundle show" and it is showing about 30+ gems even though I have only 6 gems listed at Gemfile, I am assuming the rest are core gems which get installed when I create an app, so how to lock them or should I just leave them untouched ?
I thought so too at the beginning.
But then there would be some updates which didn't quite fit to what I coded, or there would be incompatiblie changes which cause feature to stop working.
it happened to me at least twice that I would update a gem at the exact moment the gem was push and I was one of the first few to see it all break due to some bug that wasn't fixed at the time of the push. So you try to debug and it won't work. Since then, I would lock problematic gems and only upgrade them when that's the only thing I'm doing and make sure the functionality remained the same.
It is advisable to use versions which you know that work.
After that you can use gemnasium to keep track on the gems
My suggestion would be YES.
Reason being is that I view external dependencies as potential breaking points as they are out of my control to a certain extent; any change that an external dependency that isn't initiated by me is a potential for a failure.
Since software development is already complicated, I strongly feel that both limiting and controlling external dependency changes works to our advantage.
The less surprise there is the easier it is to maintain code.
HTH
One of the purposes of bundler is to pin your gem dependencies to specific versions. So on the first bundle after you added a gem to Gemfile, the gems will be pinned to specific versions anyhow. You have to specifically do bundle update <gemname> to do an update on a specific gem. Just bundle update (which updates all gems to the most recent compatible versions) defeats the purpose of bundler to a large extent and should be avoided.
that said, I think one should only mention versions in Gemfile if one has a specific reason for it. Example: You want to run rails version 3.2.8 specifically or you have to use ruby-net-ldap 0.0.1 because 0.0.2 breaks some functionality.
I think yes, because in the early days I had so many issue with gems which are updating by themselves, and not backwards compatible.
Normally this happens when you are switching from one major version to another, For me it's Rails 2.x to 3.x.
So the bottom line is it's good to have versions in the Gem file.
It's good to use the exact version numbers. You can probably always just lock it down to a major version, or never specify any version, and be okay, but if you really want that fine grained level of control and to have 100% confidence in your program when being run on other machines, use the exact version numbers.
I've been in situations where the exact version number wasn't specified, and when I or someone else did a bundle install, the project broke because it went to a newer version. This can be especially bad when deploying to production.
Bundler does lock in your gem specifications, but if you're telling it to just use a major release, then it locks that in.
Also if there wasn't a Gemfile.lock, deploying code to production would be a major issue because, as, the dependencies and gem versions could change.
Can I use two versions of a gem in one application?
I'm trying to use two Rails plugins to work together:
Pengwynn's LinkedIn for LinkedIn API calls, has an dependency on OAuth (~> 0.3.5)
OmniAuth for user login via multiple well-known websites, has an dependency on OAuth 0.4.0
When I try something in Rails I get this error message:
$ rails server
c:/Ruby187/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/resolver.rb:129:in `resolve': Bundler could not find compatible versions for gem "oauth": (Bundler::VersionConflict)
In snapshot (Gemfile.lock):
oauth (0.4.4)
In Gemfile:
linkedin depends on
oauth (~> 0.3.5)
Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
Trying bundle update freezes my terminal.
Is it possible to use both plugins at the same time?
Using two versions of a single gem usually means: use two versions of the same class.
It's not possible without making modifications to these gems. You may try to place created classes in some module, resolve conflicts in methods imported into other classes, and so on. In general, it is not easy task, and usually the effect is not worth it.
What you should do in such cases is to ask the gem maintainers to update the dependencies, or try to do it yourself.
Maybe you can downgrade (use older version of) one of these gems, to the version in which the dependencies were the same.
Unfortunatelly, in Ruby the only way is to fix (sic!) those gems, so they use compatible dependencies.
In general, when building complex software in Ruby and having such a situation we - Ruby developers - can't do much. And this is really bad, as development in Ruby has to focus on this issue as well.
Instead of providing your customer new features or change requests, one has to live with Ruby so called: "gem hell".
Another major characteristic of "gem hell" is that not always the latest gem release is the good one.
Often, a gem does not follow semantic versioning policy, and can introduce major API modifications.
Often, a new gem release may introduce new bugs to features previously working.
Other programming languages have an option of handling these types of problems. Just search for "java multiple versions of same class" and you'll find lots of resources.
What I can suggest for smaller kind of applications is to:
be up-to-date with all latest gems' releases
What I can suggest for larger kind of applications, when above is not an option:
split your application into several smaller applications, services.
This will separate them making risks of having "gem hell" smaller. If it happens, chances are it happens not to all of them.
Also, different apps can use different gem versions.
switch to JRuby where those issues can be - in theory - solved via Java capabilities.
I have bunch of Rails apps running on Rails 1.x. I need to upgrade the gems so the question is, will these old apps still work after I upgrade gems?
Thank you.
The only way to be sure is to test, of course; that said, if you want to be sure the application works while you test, I believe that you can run
rake rails:freeze:gems
to copy the currently installed gems to the vendor folder inside your project. If, after testing, your project can use newer versions, run
rake rails:unfreeze
to return to the system installed versions of the gems.
It depends. If you're talking about upgrading to the latest gems that comprise Rails then if the applications use features that were long ago deprecated and subsequently removed, then they will break.
The only way to know for sure is to try it. Look out for deprecation warnings in the development log. Hopefully you have good test suites in place.
It's just like any other dependency. Look at the version number for each gem:
1.2.3
In this case, 1 is the major version. If this number has changed, then definitely do not upgrade. It will require work to use the new one.
2 is the minor version. You should be safe upgrading if only this number has changed, but be careful. Do a lot of smoke tests.
3 is a bug fix release. You can definitely upgrade if only this has changed. It's unlikely only this one has changed after so long, but if that's the case you're safe.
Unfortunately these are only guidelines, and many open-source projects among others do not follow them very well. So take the advice with a grain of salt.
If you are running with rails 1.x and you upgrade the rails gem, your application will break. Rails 2.x is very different.
Concerning other gems, they might break. Read the releases note, usually authors warn about backward compatibility.
If you don't want to upgrade, you could also freeze the gems.