what is the best when it come to choosing what version of rails to use in your development?
I wanted to upgrade to the newest version for the new features, but in many cases chances were high that my existing code would be broken, and a lot of extra time definitely needed to spend fixing it. Should I stick with the current version of rails I'm using? or heading for upgrade?
Any advice or guideline would be really appreciated.
It is useful to always upgrade, because new gems might not support older versions of Rails and you wil get new features from Rails which could reduce code. You can do it step by step, fixing time to time code that will break in newer version of Rails. It more like continuous refactoring.
I think you have to check carefully when and how to upgrade. Here are some hints that may help in the upgrade process:
Patch versions (like upgrade from Rails 3.1.0 to Rails 3.1.1) were normally no problem at all. Upgrade whenever possible, normally you don't have to change anything. Sometimes you have to check if other Gems as well should be upgraded, read the release notes, they give (sometimes) hints about that.
Minor versions (like upgrade from Rails 3.0.9 to Rails 3.1.0) come with new features and non-compatible changes. In the release notes, you will find information what has changed and has to be proven before hand. As an example, look at Ryan Bates railscast "Upgrading to Rails 3.1.0". You normally have to do the following steps:
Upgrade to the last patch version before.
Look at the deprecated log messages. These are the ones that may break after the upgrade.
Tag your current application, or branch to be sure to not destroy anything by the upgrade.
Do the upgrade up to the point you are sure most needed features work again.
Merge back your changes, and continue with the upgrade
(Have done that the last few days for an application I have upgrade from Rails 1.2 to 2.0 up to 2.3.8 to 3.0.0 up to 3.0.9, and now 3.1.1.)
Major version upgrades are even more difficult. You have to ensure that you have enough time and resources to check all the minor glitches you may have. Most of the time, there were resources available by the Rails team that help do the upgrade, like the Rails upgrade helper or the 3 railscast "Upgrading to Rails 3".
In any case, you should at least check if the main Gems you are using (additional to the normal Rails gems) are compatible with the version you want to migrate to. This may be tricky, but sometimes, the information is available.
My experience is, that Major upgrades take time, and if you don't have it, don't do the upgrade. Minor upgrades take some time, and depending on the change (assets in Rails 3.1) come with a price tag, which is sometimes, not all of the times, worth it. Patch upgrades are painless and should be done at will.
Related
I have a product and the version is 1.3.9. It has a severe bug when uninstall it. I fix the bug and make the product 1.4.0. Then I want to overwrite the 1.3.9 version whitout unintall it. Is there anyway to do that?
Minor Upgrade: Yes, you need a minor upgrade. It upgrades the product in-place and does not trigger uninstall. After that is done you can run the uninstall - now with a corrected uninstall sequence - and you can use major upgrades again the normal way - but you need to migrate yourself out of trouble with a minor upgrade. Minor upgrades have many limitations.
Note: it is also a problem that when your next version comes along you need to provide a minor upgrade again to migrate users who are still at the problem version. There are various approaches here - such as using the same minor upgrade wrapped in a setup.exe launcher.
Clunky Version: You can also make the new version ask for the user to manually uninstall the previous version. Not a good solution, but possible. Then you avoid the need to have to deliver a migratory minor upgrade as part of future launchers?
Maintanence of minor upgrades for broken major upgrade fixing (Michael Urman of Installshield)
Various Fixes: There are many hacks and tools you can use to clean this problem out, none are ideal (do visit that link).
I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.
What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.
Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:
1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)
How such collisions are being addressed using SemVer?
Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.
It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.
My production systems, have two inputs:
Development is the product of my engineers.
Automated maintenance is the product of a system that:
Pulls patch releases and applies them to a fork of my current production code.
Tests the applied changes against an extensive suite of functional and performance tests.
If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.
There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.
While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.
How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I have upgraded my app to Rails 3.1.0, and while I have solved many compatibility issues, but I have also noticed that there are many redundant files, junk codes, and some features I have to recode again.
I am just wondering if I should just rewrite my app from fresh in Rails 3.1.0, or continue modifying and fixing after the upgrade? The former one will produce a cleaner app, but more work, and the latter one will be faster, but will also take some time to clean up the mess. What is my best approach?
Thanks.
what I do is create a fresh empty rails 3.1 app. Install my gems with bundler. Then I copy over my migrations, my models and my spec tests. Run my tests. Get tests passing, resolve any incompatibility issues. Repeat with config/routes, controllers, views, etc.
I'm just starting out in Ruby (Rails actually) and the book I'm reading covers Ruby 1.8.6, RubyGems 1.0.1, Rails 2.0.2 and SQLite 3.5.4, but the current stable releases of these are 1.9.1, 2.3.8, 1.3.7 and 3.7.0 respectively, should I still proceed with the book or find another?
Also, I couldn't find a recent guide/tutorial to walk me through the installation of these latest versions, would be great if you could help with that too. I'm on Mac OSX Snow Leopard (10.6.4).
Many thanks!
There are a large number of projects with major release milestones just around the corner. These include Ruby 1.9.2 (the 2nd RC is already out), Rails 3.0 (the RC is already out), and a number of other libraries and plugins. Please note that Rails 3 does not support Ruby 1.9.1, although it does support 1.8.7 and 1.9.2.
I would start out with Ruby 1.9.2-rc2 and Rails 3.0.0.rc. These are what will be the current version over the next few years, starting within the next few weeks. Previous versions of Ruby and Rails will be legacy.
Look for new editions of books coming out, having been updated for Ruby 1.9.2 and Rails 3.0.
I were like you. Although Ruby is popular, they are very bad and inconsistent in such kinds of various versions. Firstly, I thought that the latest version is always the best, which holds the true for most languages. Later, in these days, due to the removal, re-structure and redesign of logic and underlying codes, the latest version is not always good for programmers who are used to writing codes in older version. See python case (2.x vs 3.x).
So, for ruby, if you're holding a book that teaches you in ruby 1.8.x, then just relax and adhere to 1.8.x. Install 1.8.x version and Practice. Same for 1.9.x and other versions. Or else you'll end up with frustration like "why doesn't my code run?".
The most important thing is RubyGem. RubyGem is also stick to ruby version. Gems that run in 1.8.x are not usually compatible with 1.9.x. So, keep that in mind. Or else you're unhappy that you install this gem and you can't call it - its objects.
Now, my practice is that I install every version. I exclude ruby path and its lib in PATH variable. When I want to switch between each version, I use BAT/bash file that set variable for each version like PATH=$PATH:/opt/ruby18 .
I've also asked many questions about this in many forums. As you know, the life and true aspect of programming is to (re)use libraries and objects. If certain libraries don't work with a certain version of ruby, then you have to switch to others. This is also my bad feeling about ruby. They really should have backward compatibility.
Maybe others can solve this problem smarter than me. But it really messed up with my programming life.
Checkout RVM, use it to install different versions of Ruby/Rails on your machine without root access. It will make your Rails development easier :)
railstutorial.org walks you through the installation of everything you need on OS X. It's also more recent than the book you're using.
Take your pick, the Rails book or the version that you specifically need to learn.
Once you decide on a book, install the versions of the language / gems as mentioned in the book. e.g. Rails 1.2 and Rails 2.0 had pretty big differences and the tutorials wouldn't work.
If you're learning Rails, pick a well known book, install the specific gems. Once you're done with the book, you'd be in a better position to look at the differences and migrate to higher versions with less hassle.
gem list rails --remote
gem install [gemname] --version [version]