3 ms·
Here's the upgrade logic I would use for your use case: * Is your accounting application exposed to the Internet? Then I'm going to recommend an upgrade for ev
by awj 13y ago
Here's the upgrade logic I would use for your use case:
* Is your accounting application exposed to the Internet? Then I'm going to recommend an upgrade for every security release. Because your app is probably handling something sensitive enough that you'd want to protect it.
* If your app isn't on the open Internet, it probably needs upgrades at each minor release at most. Maybe not even then, but minor releases of Rails often include features that are meaningful to end users.
* If we're already working on other changes I'm likely to try to bundle the version upgrade as part of it. Mostly because staying current means I can reduce new feature costs to you by the new/updated libraries I otherwise wouldn't be able to use.
Sound better?
- johnchristopher 13y agoI have an issue with your point #2: how does the app end-users ends up with new features when bumping a minor version of the framework behind the app ? Aren't the end-users of Rails the developers and not the end users of the app ?
- awj 13y agoBest example I have is that Rails 3.0 -> 3.1 included the asset pipeline, which enabled some pretty nice speed improvements by making better use of the browser's caching system and minimizing the number of file downloads required for css/javascript. That said, yeah, that is why I was wishy-washy on that suggestion. The payoff in minor version upgrades is keeping on top of upcoming deprecations, which minimizes future upgrade costs. > Aren't the end-users of Rails the developers and not the end users of the app ? Developers don't work in a vacuum. Many "developer niceties" of Rails translate into reduced end-user costs due to faster time to execute change requests. This is an important thing, but it's also hard for both sides of the transaction to quantify.