You might think, "I'll just lock onto a specific version of Devise." But you can't always do that if you want to update other gems. Eventually, you'll have to deal with Devise.
For example:
Poor Lucasz. He updated his gems but didn't run the migration.
Ok, actually Devise is not actually bad. It's extremely useful. It takes care of the boilerplate code around your user models. If you want your users to have the ability to log into your app after they forgot their passwords, it's great for that. In fact, all of the features of Devise are great. You should use Devise.
However, it's a very big commitment. When you're developing a greenfield app, Devise is a huge asset. It takes care of so many things so you don't have to. But there's a price. When your app goes into maintenance mode, Devise might demand some extra time. So, when you're creating your price structure and you want to correctly predict how much maintenance will cost, remember Devise in your calculations.
Strategies
Here are a few strategies for dealing with projects that will implement Devise:
- Copy Cat - One strategy is to use Devise as a guide for features you need, and only implement those. Say you want e-mail confirmation and "forgot my password." Take a peek into how Devise goes about it and then just write your own.
- Periodic Updates - Before you update any other gem, update Devise and see where it's at. You'll have to brush up on Device every so often. But in order to update that one gem you really want to update, somehow, Devise will pop up.
- White Knuckle - Just throw up your hands and become the biggest fan of Devise. For this strategy, you'll need to follow the github issues and every commit. Honestly, who is that interested in this topic enough to get excited? I mean, Devise is great and all, but who really cares once it's working? But if you don't do this, you'll get a rude awakening when you realize you need to update Devise.