[FEATURE] Add option to version lock gems

[kevinvangelder]

I don't like manually version locking gems but version locking is an important part of many people's development process. It would be great if there was an option to lock all gems at the latest major version when using the Rails Composer to set up a new site.

[DanielKehoe]

Tell me more about the use case. How often do you find you need to lock gem versions? Do you lock them all or just ones you know can't be updated without problems?

[kevinvangelder]

My boss is trying to get us to version lock everything (to major versions, minor version changes are usually okay). Other people would probably have other use cases (like minor version locking for larger corporations) so it might make sense to offer None, Major, and Minor options. I don't think anyone ever needs to lock to patch-level, but I could be wrong.

[DanielKehoe]

What is his reasoning for locking to major versions on every gem? I think it is more common practice to only lock when a gem becomes incompatible. Conflicts only arise when you run "bundle update" and presumably you can roll back and lock at that point.

[kevinvangelder]

We work on a lot of smaller sites, so if someone on the team clones a project 6 months after it launched they'll get potentially-breaking gem versions when they bundle install. Your points make sense in a single-developer situation but don't work so well in our multiple-developer situation.

@jamonholmgren, anything to add?

[jamonholmgren]

I like to run bundle update at any point to get the latest security and patch level releases without breaking everything. For gems that follow semver we should be able to lock to 1.x (etc) and there shouldn't be backwards incompatible breaking changes. That's why locking to major version is helpful.

Examples of this where it has caused problems include RSpec, haml, and in the case of a middleman site activesupport updating from 3.2 to 4.1 caused problems. Yes, we can revert and lock when we notice problems, but it's better to be proactive.

Of course, this isn't necessarily rails-composer's problem, but Kevin must think it is. :-)

[kevinvangelder]

Not a problem with rails-composer so much as something that would be very convenient (hence the FEATURE flag in the title).

[DanielKehoe]

Thanks for the perspective. When you use Rails Composer, do you build a RailsApps starter app, or do you choose the "build your own" option?

[kevinvangelder]

I always use the "build your own" option as each site we build have fairly unique requirements. I understand if you give this feature a low priority as it may not be useful for very many of your users. Maybe sending out a poll to the newsletter group would be a good way to prioritize features? Regardless, thanks for considering the request. :)

[DanielKehoe]

Thank you for your interest and support of the project.

[tomelam]

Here's my use case for locking the version of a gem. I am trying to avoid using the combination of ruby-2.3.3 and rails-5.0.1 because Rails Composer produces a NoMethodError (undefined method `confirm') when I choose the custom application (build-your-own) option and devise with the invitable-and-confirmable option. Unfortunately Rails Composer is not honoring my choice of ruby and rails combination, because it seems that Rails Composer automatically creates a Gemfile with the rails specified to be '~> 5.0.0'. Thus when I run 'rails --version' it shows rails-5.0.1 and when I run Rails Composer with my choice of options I get the NoMethodError.

Hand-editing Gemfile and restarting the assembly process would be an acceptable alternative for me, but how can I get all the recipe stages to complete properly?

[DanielKehoe]

@tomelam Rails Composer does not set the Ruby version or Rails version. You get whatever version is in your environment when you run Rails Composer. For your problem, how about choosing the default Devise option (without invitable-and-confirmable) and installing invitable-and-confirmable for Devise manually.

[tomelam]

@DanielKehoe Sorry for the long delay in responding to your comment. I hope you are well somewhere in the world. Today I was cleaning up Google Chrome's Tab Outliner bookmarks and noticed this conversation between you and me.

What I did was fork Rails Composer and rails_apps_composer and changed the Devise recipe to use confirm! (if I recall correctly). I think I created a push request so you could get this change into your repo.