[jrochkind1]

I think ActiveJob is a great thing, a real step forward to have a Rails-endorsed API for this others can hook into on both sides. Awesome.

But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? So many things to upgrade, so many dependencies that might break, and then Rails 5 coming in less than 12 months when I get to do it again, I have to admit the Rails treadmill is exhausting me.

[username223]

> But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version?

Welcome to modern software. I'm not on the Rails treadmill, but arbitrary breakage every month/quarter/year, possibly enforced by a hard-to-disable automatic update system, seems to be the new normal. Heaven help you if you write or use software that depends on "modern" software.

[lotyrin]

Hard to disable? Most of the dependency tracking tools I'm aware of, spanning from system level to application level, require you to intervene by default, even in the case of security releases and/or even have nice version pinning features.

As the maintainer of an internet facing application, it's part of your ongoing responsibility to, for security reasons, continuously integrate upon your dependencies.

Nothing's fire and forget, it's not sensible not to stand on the shoulders of all these giants around us, but when we do we have responsibility to integrate their security fixes and not break our apps.

Not sure where you draw your line of what"modern" software is when not even system packages and package managment are safe when we have Heartbleeds and ShellShocks, Kernel Vulns et al.

Unless you just mean the bros pumping out new NPM modules/Rubygems/etc, half-assing SemVer, disregarding compatibility as a goal, and only releasing fixes (security-related even) for the latest major version that came out several months ago, or abandoning them. Yeah, that's some serious BS and I hope things mature.

[ploxiln]

Just today I learned that a version of requests from August broke compatibility with a version of pip from February, which is packaged in ubuntu 14.04. (I was installing dependencies with apt and pip as root in a docker image.) (http://stackoverflow.com/questions/27341064/how-do-i-fix-imp...)

Meanwhile, openssl and bash, while getting security updates very recently, are in their very latest versions still compatible with programs from probably over 8 years ago.

[ayrx]

"Meanwhile, openssl and bash, while getting security updates very recently, are in their very latest versions still compatible with programs from probably over 8 years ago."

You have obviously never worked with OpenSSL.

Also, the problems with `pip` is entirely due to Ubuntu not updating their dependencies properly. Upstream `pip` vendors their dependencies so that this precise situation does not occur.

[ploxiln]

That does make sense. Since pip is managed this way, Ubuntu should probably classify pip as "not system software, actually flaky web-app-dev software" and not package it.

[bigtunacan]

> half-assing SemVer

This is an ongoing and IMO major problem. Even security patch releases are breaking backwards compatibility and causing constant rework.

If the platforms aren't going to honor the contract of semantic versioning then why even bother to use it?

[username223]

> half-assing SemVer, disregarding compatibility as a goal...

Like Chrome and Firefox, which toss out something-or-other every few months, call it a "major version," and force-update users by default? Or Windows and Mac OS, which by default offer some kind of "udpate now or remind me in 30 minutes" dialog for both backward-compatible and breaking changes? It's all just complete disdain for users.

[lotyrin]

Oh, certainly. I was thinking we were speaking developer experience within the realm of building/hosting network services, not so much end-user experience for client software.

That space is still a special hell for lots of reasons. Auto updaters that steal your features away being quite inexcusable but yet also not chief among them for most users.

It seems it still takes a software engineer to work the average client OS and not get it infected with crap. Maybe the average child can operate a shared walled-garden device without exposing their family's sensitive documents to untold numbers of developers of third party software on accident (or on purpose, yay Minecraft Mods!), but that's certainly not true of general computing devices.

Lots of paid (or ad-bloated) software that's lower quality than free alternatives but with cash to spend on a marketing budget, and that's not a high bar given that generally FOSS for end-users performing day-to-day tasks on client devices is still really sad.

[xorcist]

I've had luck with a stock Ubuntu install for the parents on both sides of the family. I set it up some eight years ago, installed printers and such, set it to auto update, and help them run the LTS uprgrade every other christmas. YMMV of course, and neither run minecraft mods or install crap from the Internet as they are basic web/office/audacity(!) users.

[tomcam]

Not true at all. web2py is infinitely more capable than rails and has been compatible in all releases since 1.0, over 7 years ago.

[tomcam]

Would like to understand reason for downvotes...

[rhizome]

Were you actually being serious?

[nazgob]

web2py is not comparable to rails.

[douglasfshearer]

Rails used as intended can be a real pain to upgrade, I agree.

Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required.

[1] https://github.com/garybernhardt/sucks-rocks [2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome... [3] http://objectsonrails.com/ [4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.... [5] https://www.youtube.com/watch?v=CGN4RFkhH2M

[rapind]

Anyone else thinking "EJB on Rails"?

[whistlerbrk]

I don't. I feel like the deprecations and API changes have mostly been quite minor since 4.x. A lot of this is shedding weight from supporting Ruby 1.9 and 1.8.7, so if you've been up to date on that front (gem and code wise) you've been okay.

I'm looking forward to 5, but I'd like to see what the feature set is. Namely building real time and concurrent apps in _Ruby_ doesn't feel natural on _Rails_ and I hope it can be.

[reledi]

I get excited about every stable release and try to switch as soon as possible. When you keep up with the incremental updates then the upgrade process isn't too bad IMO.

[adriand]

That's easy when you have just one, or a handful, of production projects to maintain. When you have hundreds it's a vastly different story. But that's where I think https://railslts.com/ comes in.

[websitescenes]

Upgrading between from 2.x to 3.x or 3.x to 4.x can tend to be tricky but I have not had many, if any, issues upgrading from 4.x to 4.2.

Typically if a functionality is removed or deprecated from the framework, you will find a gem will popup that can be included so your legacy code still functions. I often take this approach since we maintain mountains of Rails apps from 2.x to 4.x.

If you are working on a handful of apps or a single app, I think it is worth it to stay as current as possible and update with every new release. Your knowledge of the framework and the quality of the product will increase with every iteration.

[DAddYE]

Usually if I have a production project I avoid to step out through major releases.

As you have seen they do bug fixes for previous stable releases, which is awesome and IIRC the security one go even deeper to the tree.

No one force us to upgrade, but I do love upgrades, usually (if well done like this one) are full of things that may help our coding life and speed performances? Are always well welcome!

[mbesto]

I'd love for Rails to have some incremental LTS releases. Not that the Rails organization itself has to provide support, but rather the community decides which releases are most suited for LTS support. This would force gem providers (and automated CI's) to test on those releases.

[alxndr]

Have you seen https://railslts.com/ ?

> "Rails LTS is a commercially supported fork of Rails 2.3 (and soon Rails 3.2) that continues to receive security patches now that official support has ended."

[hmans]

Unless you need one of the new features on offer, there is no reason why you would need to upgrade right away. It's perfectly okay to give a new Rails release a couple of months to settle, including gems that need to be compatible with it.

[gareim]

I just started learning Rails and haven't deployed yet, but the thought of upgrading after deploying a project scares me a lot.

[diasks2]

I've found the best way to make upgrading easier is having good test coverage. I think one of the biggest fears when upgrading is having something break but not knowing that it is now broken. Although tests won't always catch everything they are a great start to ease the upgrade process.

[cies]

To have tests (and particularly integration tests) is a big help; as has already been mentioned.

Another thing is to use staged deployments: dont deploy to production-env from you development-env, but to a staging-env (if possible using the same or a copy of the live database). Then have a look with some (possibly non-technical) humans if the app still behaves as expected.

While it can be laborious for a large app, it should make a deployment to production a lot less scary.

As mentioned by others: upgrading is part of running a web app that depends on popular libs.

[patrickdavey]

Why does it scare you? It's good to be wary of the upgrade process.. but this is why you have (I hope!) database backups and source control (as a minimum). Then at least you can roll back. Then it's just extras after that, test coverage, staging servers etc. etc.

Anyway, upgrading is a fact of life once you're using a framework (unless you want to get hacked) so best to get used to it :)

Good luck!