Keeping Ember up-to-date can be a relatively straightforward process if you’re lucky (See Part I). Otherwise, it could feel like a full-time job in its own right. If you’re building an ambitious application (and why else would you be using Ember?), it’s quite likely that upgrading has been a bit more painful for you. There are deprecations, changed internals, and all sorts of other pitfalls that can trip you up and make this task feel impossible. However, it can be done, and perhaps I can impart some tiny amount of advice to help you have a better day when you do it.

The Sad Path

Let’s start by talking about what probably won’t work for you. If you’re several versions behind (or more), I wouldn’t recommend just picking the latest version of every package your application depends on and hoping there aren’t any regressions. Blindly upgrading every dependency all at once is unlikely to be a successful strategy, and we certainly wouldn’t expect any reasonably complex application to survive such a massive change.

It may seem common sense to avoid this path, but so often we as developers just want to bump all of our dependency versions and hope they work, since we generally know next to nothing about the random third-party implementations the application relies on. However, doing this will likely lead to one of two outcomes:

1. Your app will break into a million tiny pieces and you’ll be left with no idea what is causing the explosion.
2. Even worse, everything will appear to work correctly, but in fact there will be unseen bugs lurking around in your code now, waiting to bite you in the ass.

Prepare For Unforeseen Consequences…

Now obviously, there’s no such thing as a substantial project being completely bug-free, and fear of issues isn’t a reason to avoid new versions altogether if there is some other benefit to be gleaned from the updates. Even so, blindly upgrading en masse is unlikely to be a successful approach in the long term.

If you’re worried about whether the resources and blog posts you find online contain information that is still relevant to the latest Ember release, you might be interested in checking out the Ember Community Versions project. This effort “provides helpful badges with versioning information to community resources, like blog posts”. That is, the lofty goal is to tag web content, both old and new, to mark which versions of Ember are relevant for that information. Ideally, you can use these badges to identify content that works for your current version of Ember, as well as what you should bookmark for future upgrades. This is a community project, so you can help by submitting Pull Requests for existing content you find out there on the web.

The Piecemeal Path

If running  `ember init` causes issues in your application, don’t despair! Think of that command as a blueprint (which it literally is!) for the end goal of your upgrade. Then, go back and apply the new packages in smaller groups so you can narrow down the cause of the problem. I generally follow this process:

1. Create a branch `ember-upgrade` with all of the basic changes given by Ember-CLI and commit them.
2. Create a second branch off master to use as a blank slate.
3. Create a squashed merge via `git merge ember-upgrade –squash`.
4. Select a subset of the changes (perhaps a few Bower/NPM packages that Ember depends on) and revert the rest.
5. Test your app with these changes to see if the bug persists.
6. Repeat steps 3-5 until you reach a state which reproduces the issue, then narrow down which package upgrade (or combination thereof) caused it.

The pattern above may sound somewhat familiar if you have heard of Git Bisect. While in this case you won’t have separate commits allowing you to utilize that amazing tool, the idea is basically the same; work through the changes bit by bit until you can narrow down where the issues start occurring in your application. This piecemeal approach allows you to perform most of an upgrade so that you can reap some benefits of new versions immediately while focusing in on a blocker issue at the same time.

Check out Part I of this series to learn about the optimal upgrade path for Ember.

Read on to Part III for dealing with deprecations before moving to Ember 2.0.

Special thanks to Thomas (@djvoa12), Spencer (@spencer516), and Ben (@bdvholmes) for reviewing this series!