Security support for Rails is described on this page: https://guides.rubyonrails.org/maintenance_policy.html
As I read this, my expectation is that when Rails 7.0 is released, likely in April 2021, the 5.x series of Rails will no longer receive security-related updates and bug fixes. Is this correct?
More importantly, upon release of Rails 7.0, it seems like only the last minor release of Rails 6.x (currently, 6.1) will receive security updates. To be explicit about this, when 7.0 is released, I expect that Rails 6.0 (not being the current minor release of the 6.x series) will no longer receive security updates. Is this expectation correct, or will the 6.0 minor version also receive security updates after a 7.x release?
Any further definitive guidance or clarification on how this works would be helpful, as the linked documentation above is unclear, and this directly impacts the security of customers I support. (Preemptively, I am not interested in 3rd party security support of older Rails versions.) Background: I use gems that are as of yet incompatible with 6.1, but are supported in 6.0.
Related
I'm just trying to understand the factors that are considered to decide that an application written in a lower version needs to be upgraded.
I would like to think it comes down to these factors:
The Rails team is pretty active and they remedy Rails core security issues as soon as they come across one. It would be nice to have your Rails version always updated which means your have all the security issues of the past addressed as well as open to further updates if they come along. You would not want an older version of Rails get in the way of a security update.
There are always performance improvements in almost every new version of Rails and optimization is an area to work in for Rails apps. You should take advantage of them by keeping your Rails version updated.
Its not only the Rails version, the underlying Ruby version also receives updates and performance improvements. The updated version of Rails makes use of these.
There is also the gem dependency issue. Gems also receive updates and security patches and at times, newer versions of these gems are not compatible with an older version of Rails.
It is easier to upgrade a Rails application to its next version than to its next|next|next|next version. Blog posts and migration guides are always online but if you are coming from a very very old Rails version, they will become very hard to follow.
Newer versions of Rails provide functionality that is not available in the older versions of Rails. It is always nice to have this functionality at your disposal. You never know you may need it in your project.
I made an example project in grails 2.3.8. How to upgrade to the newest version? No way to downgrade from version too?
It really depends on the differences between the versions. In a lot of cases you will get away with simply editing the version number in the application.properties file at the top of the project. There used to be a grails upgrade command which attempted to do some of the work for you but that approach proved to be problematic for a number of reasons so it was removed in Grails 2.4. The normal upgrade procedure now is to edit the version number, which can be done using the grails set-version command (which just updates application.properties, see http://grails.org/doc/latest/ref/Command%20Line/set-grails-version.html) and then reading release notes for any other particulars related to that release. Often the release notes suggest updating some specific plugins to specific version numbers for compatibility.
Downgrading generally could be done with the same approach. Depending on what is in your application you might run into problems going backwards in versions.
I hope that helps.
I have been working with rails 2.3.5. I am gonna start a new project on rails. Should i continue using the earlier version or should i hop on to rails > 3 ? If so which is the more stable version?
It is better to use rails 3.0.x version as these days lot of new plugins(like active_reload) are targeted only for 3.x version.
3.1.x have lot of cool features(like asset pipeline, saas integration, coffescript integration, etc), but its still a release candidate and I faced some issues while using it. I guess we have to wait for the stable 3.1.x release.
I have been using 3.0.7 for a while and found it to be very stable.
3.0.10 is recently released and you can easily upgrade to it from 3.0.7 any time you want in the future.
If you are stuck to 2.x version you will be missing cool features like mentioned here: http://net.tutsplus.com/tutorials/ruby/5-awesome-new-rails-3-features/
For a new project, I would use Rails 3.1 or for a bit more stability, 3.0.7. There are some noticeable differences compared to 2.3, but it will be supported for longer and most development of new gems and documentation are being written for Rails 3.
You should definitely NOT use 2.3 and earlier.
The Rails framework is improving at a steady pace and if there is a downside to that is that it can be a pain to upgrade from version to version, especially as regards to major version changes which introduce tons of backward incompatibilities.
Why then would you want to put yourself in the hole at the get go.
Another issue is how ready and mature is the ecosystem (ruby, popular gem packages, etc.). This leads you to consider whether you should start with 3.0.10 or 3.1 release candidate.
It turns out the great majority of gems working with Rails 3.0 is also working fine with Rails 3.1.
The little downside is that 3.1 is still in release candidate status but it's all but ready for final release and that should come within a matter of days or maximum a couple weeks (as of today Aug. 25, '11).
I would strongly recommend you start all new apps with 3.1. That's what I'm doing.
I am a few weeks from hopefully launching my site (Yes, I know like I may be tempting fate, even merely asking this question).
I am developing using SF 1.2.9 (using Propel ORM), but I am increasingly being tempted to upgrade to 1.4, least of all, I feel it will be less of an effort to migrate a life system from 1.4 to 2.0 later on, than from 1.2 to 1.4. Also, IIRC, active support for 1.2 is being phased out next year, whereas 1.4 is to be supported till 2012 (IIRC).
So, shall I bite the bullet and upgrade, or shall I take the (on the face of it - safer) option and stay put with 1.2.9?
If you want to use some of the new features, you should upgrade of course. As the symfony development is test driven, I assume the new versions are stable and reliable.
But: Do not upgrade to 1.4 but to version 1.3. The later has an extra compatibility layer to ensure that projects based on 1.2 still work. There are some internal changes in 1.4 that forces you to really refactor some parts of your project to keep it working. With 1.3 you can make this changes step by step.
The only differences between 1.3 and 1.4 is this compatibility layer. For specific instructions, read this upgrade guide.
As for support, 1.3 is supported until the end of next year which gives you plenty of time to upgrade to 1.4 step by step.
And in general I belief also that upgrading from 1.4 to 2.0 will be easier than from 1.2.
Edit:
You can find the changes here and the deprecated stuff here.
I don't know if 'internal changes' was the right word. There is some stuff you have to consider if you change to 1.4 but the deprecated stuff in 1.4 still works in 1.3.
I will try to upgrade one of my projects to 1.3 this weekend and I can give you feedback somehow if you want to.
Are their any compelling reasons for the upgrade? Does version 1.4 have more bug fixes, or additonal features that your appliation must have? Are their any breaking changes between 1.2.9 and 1.4? Is there any refactoring to do after you've upgraded to 1.4 from 1.2.9?
I'm looking at this from a .net framework perspective;
.net 1.1 to 2.0 - there were many changes here. many of them were breaking changes, but the benefits of the upgrade were great.
.net 2.0 to 3.0 or 3.5 - a lot of upgrades were introduced here, but not very many if any breaking changes since the last two upgrades were based on the same basic framework. You can live with the 2.0 version without upgrading to any of the other two.
So if the Symfony upgrade is similiar, I would wait for a little while. You've got your application built, tested and ready to go. See what it takes for the upgrade and then see about integrating the new features in during the next iteration of your development.
Good luck with your site, and hope this helps some.
A client is indicating that the Rails version I have installed on my Ubuntu servers (2.3.4) is not backward-compatible with the older Version 2.3.2.
I want to know if that is true or not before I attempt to install the older Rails.
the beauty of rubygems. just install both versions and have them specify which version in their environment file problem solved who cares if its compatible or not
New features are never backward compatible.
Well, it is possible that you are using features that are only available on version 2.3.4 , and therefore they're not on version 2.3.2.
Check its changelog to see the differences.
Upgrading between even minor Rails versions often causes problems with old apps.
That said, 2.3.4 is the current recommended stable version so it would probably be worth biting the bullet and getting the 2.3.2 app running on it. Probably won't take very long, if you've got a decent test suite.
There are also a few of bugs that are introduced. Like this one I found involving named scopes using includes. That was introduced in 2.3.3 and wasn't fixed in 2.3.4
2.3.2 => 2.3.4 has been the most painless upgrade so far for us (large app with lots of legacy, rails 1.x code).
The only major issues we had were with after_initialize vs exists?.
It all varies app by app. If you are hosting a client's app, then you should provide gems of all rails versions (they will happily sit side by side (90% of the time)).