Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow lockfiles to receive a customized name #59

Open
aogata-inst opened this issue Apr 6, 2023 · 3 comments
Open

allow lockfiles to receive a customized name #59

aogata-inst opened this issue Apr 6, 2023 · 3 comments

Comments

@aogata-inst
Copy link

We tried to use bootboot for Rails version upgrades and found it limiting to be forced to use the names Gemfile.lock and Gemfile_next.lock.

In our case - we wanted to use something like:

Gemfile.rails61.lock
Gemfile.rails70.lock

so it was easier to understand which lockfile corresponded to which version, more useful git history, etc

@davidstosik
Copy link

Hello @aogata-inst! 👋🏻
That is an interesting idea. In order to add some context to your issue, can I ask exactly why you needed that?
Are you currently running your application on Rails 6.0 and trying to prepare in parallel upgrades to 6.1 and 7.0?

If so, have you considered focusing on and accelerating your upgrade to Rails 6.1 first? (Support for Rails 6.0 ends in about two months!)

I can't imagine any scenario where I'd want to prepare for two upgrades in parallel, instead of focusing on one then the next. I'm sure it would help people maintaining this project if you could provide us with more details! 🙏🏻

@aogata-inst
Copy link
Author

Hi @davidstosik - No problem!

We aren't trying to upgrade to 2 different Rails versions in parallel, rather we were looking for a mapping like:

Gemfile.lock => Gemfile.rails61.lock
Gemfile_next.lock => Gemfile.rails70.lock

By adding the rails version number to the lockfile name, it would allow us to be able to derive what each lockfile represents by just looking at the file name instead of having the meaning drift over time.

One other thing I forgot to mention is that instead of the DEPENDENCIES_NEXT variable - we would also have wanted something like DESIRED_RAILS_VERSION=6.1|7.0 for similar reasons.

@davidstosik
Copy link

Hmm. My personal opinion is that I'd rather have a single Gemfile.lock that'll track gem updates over time, rather than having to start from a fresh file with no git history every time the application bumps Rails.

Will have to let other people comment on this. 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants