given a gemspec project with Gemfile.lock including outdated versions, a bump minor updates the gems version in Gemfile.lock ... but it should only update the version of the gemspec gem ... I tried with --conservative flag, but that's not supported for a bundle or bundle install 🤷‍♂
so only workaround I can see if either setting some config flag or running bundle update <gem name> --conservative (might be tricky to find the name)
this seems to be triggered by the ruby version I'm on not matching the version it was last bundled with ... so this might be unfixable since it needs to bump to be able to bundle :(

• https://github.com/gregorym/bump/releases

also changelog missing.

by ci broke recently:

$ gem install --bindir=/usr/local/bin bump
ERROR:  Error installing bump:
	bump requires Ruby version >= 2.2.0.
ERROR: Job failed: exit code 1

can't even find to what version i should lock to

Running rake bump:X now shows the deprecation warning

[DEPRECATED] Bundler.with_clean_envhas been deprecated in favor ofBundler.with_unbundled_env. If you instead want the environment before bundler was originally loaded, use Bundler.with_original_env(called at /.../gems/bump-0.9.0/lib/bump.rb:160)

I would like to be able to specify a flag, say --version, that updates to the version specified. The idea is the same behind yarn's yarn version --new-version <version> command.

With this Rakefile

require "bundler/gem_tasks"

require 'rake/testtask'
require 'bump/tasks'
Bump.tag_by_default = true

Rake::TestTask.new do |t|
  t.libs << 'test'
end

desc 'Run tests'
task :default => :test

I get

NoMethodError: undefined method `tag_by_default=' for Bump:Module

bundle will update the gemfile.lock with the new version, otherwise after we publish the gem we have local changes

Semantic versioning supports a metadata version denoted by appending a plus sign. It declared in semver spec item no 10.

https://semver.org/#spec-item-10

10. Build metadata MAY be denoted by appending a plus sign and a series of dot-separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

In my case, I need to attach the build information like a short commit embedded into version information. I've tried to define a version like this in the VERSION file 1.0.0+a34wsfr. But when I tried to run bump current it returned 1.0.0 instead of 1.0.0+a34wsfr. Is it expected? And how to properly set the build version within this gem?

Using the commands in this order:
bump set 1.0.1-SNAPSHOT
bump set 1.0.1

Should result in final version being 1.0.1, but it is still 1.0.1-SNAPSHOT. The replace seems to only replace numerical characters.

Please extend this. Thanks!

How could the tag_prefix = "" be made the default for a Rakefile?

In other words, I want no prefix:

$ rake bump:patch
1.0.1

Instead of the default prefix v:

$ rake bump:patch
v1.0.1

It would be very nice to have a timestamp added somewhere. For instance, a VERSION_TIMESTAMP alongside the VERSION file.

Use case: I wished to display at the footer of my Rails app the current app release version and release date/time. It would be very usefull to parse Rails.root/VERISON_TIMESTAMP to load that info into a constant on app initialization.

Bump is a gem that will simplify the way you build gems. https://github.com/gregorym/bump <- remove the url

@gregorym

I think the more often used term is patch, e.g. jeweler uses it, rails and http://semver.org,
are you ok with renaming it?

The current pre-release bumping (implemented in #11) is very naïve and not really intuitive:

» rake bump:current
Current version: 1.2.3
» rake bump:pre
Bump version 1.2.3 to 1.2.3-alpha
» rake bump:pre
Bump version 1.2.3-alpha to 1.2.3-beta
» rake bump:pre
Bump version 1.2.3-beta to 1.2.3-rc
» rake bump:pre
Bump version 1.2.3-rc to 1.2.3
» rake bump:pre
Bump version 1.2.3 to 1.2.3-alpha
» rake bump:pre
Bump version 1.2.3-alpha to 1.2.3-beta

If you need e.g. three beta versions before moving to a release candidate, bump is of no help.

I would prefer if repeated calls to bump:pre increased a number. Perhaps that requires separate bump:alpha, bump:beta and bump:rc commands?

» rake bump:current
Current version: 1.2.3
» rake bump:alpha
Bump version 1.2.3 to 1.2.3-alpha1
» rake bump:alpha
Bump version 1.2.3-alpha1 to 1.2.3-alpha2
» rake bump:beta
Bump version 1.2.3-alpha2 to 1.2.3-beta1
» rake bump:rc
Bump version 1.2.3-beta1 to 1.2.3-rc1
» rake bump:rc
Bump version 1.2.3-rc1 to 1.2.3-rc2
» rake bump:rc
Bump version 1.2.3-rc2 to 1.2.3-rc3

Hello is there a way to separate the bump in two commands?

The first command to:

1. bump the version in the version.rb
2. add the version to Changelog.md
3. bundle update

I then want to go in and write my information in Changelog.md

Then I want to commit with the automatic message and tag the commit.

Here is our CI script and we need to use send because there is no ability to get next version without tagging

My suggestion is to move next_version method to public

I will submit PR for this change

I'm about to submit a PR to bump rspec to v3 (for features like fit and simplified boolean tags, etc).

Since implicit should syntax is deprecated in RSpec 3, would you prefer the syntax be set to should explicitly or just switch to expect syntax directly?

otherwise getting

Unable to find version 1.9.1 in gemfiles/rails52.gemfile.lock

Sometimes when working on a project with a larger codebase just bumping a single digit at a time doesn't quite work, and the version needs to be able to be manually given, so as to avoid numerous bump messages in the commit log. I don't see a way to do this currently with bump.

I would like to contribute a pull request, as all of the framework is currently in place to support this. I'm just not sure how this would want to be handled when running from the command line. I was thinking of identifying the version number, and passing it with the options hash as :version.

the only way the .lock would change is if I work on a gem that has a .gemspec ... right ?
... so ok to add that "look for gemspec" logic ?

@gregorym

https://rubygems.org/gems/bump/versions/0.9.0

I'm using Circle CI to build and push our gems directly to our gem repo. I'd like to be able to append a message ([ci skip] in this case) to the commit so Circle won't run tests.

Something like this is what I'm thinking:

Bump::Bump.run("patch", commit_message: '[ci skip]')

which would result in the message: 'v1.2.3 [ci skip]'