Open jaredbeck opened 3 years ago
bunup
operates in the context of a Gemfile, so this would step out of those bounds. Not against the idea though, we do a similar thing in libyear
where we also check for the Ruby version (maybe we should check the gem
and bundler
versions there as well).
Given that this change would be out the bounds of a Gemfile, we could either/or add flags to enable/disable, and also add a confirmation step like we do with major release semver updates.
Thanks for the quick feedback!
My motivation here is that bunup depends on bundle outdated
to be correct. Some recent bundler versions have bugs in outdated
, like https://github.com/rubygems/rubygems/issues/4451.
So, at a minimum, I think a warning is warranted, but I think it'd be convenient to automatically update gem
and bundler
. For experts who must use old versions, we could have CLI options like --no-update-rubygems
, and --no-update-bundler
. I'd suggest we avoid interactive prompts, so that bunup can be used from non-interactive scripts.
That all sounds good. I think the interactive prompt should be the default because the primary use case is updating a project's dependencies which should require some interactivity for some semver updates. We do have the -y --yes --assume-yes
for bypassing the prompts.
I can look into adding this soon. I've been meaning to give the bunup a good once-over.
We do have the
-y --yes --assume-yes
for bypassing the prompts.
Oh right, there's a prompt about major-version updates, isn't there? I forgot about that.
We'd phrase the prompt so that --yes
would automatically update gem
and bundler
?
I can look into adding this soon.
It's not urgent, just a random thought I had, but if it interests you, go for it.
Before running
bundle outdated
, it's desirable to have the latestgem
andbundler
.Should this be automatic? If so, should there be a CLI option to disable it?