tpope / git-bump Goto Github PK

Sometimes it’s useful to prefix the version with something other than v (e.g. some projects use v.; Debian packaging uses upstream/ for upstream sources and debian/ for Debian packaging), or none at all (date-based version numbers usually don’t have any prefix).

While I understand you seem to prefer no configuration for this tool, I would appreciate if git-bump supported these workflows one way or another, be it some clever autodetection or configuration. I’m willing to write patches if we can agree on an approach to this 🙂

I'm not sure exactly what the issue is here - git bump tries to set a tag that has already been set, git bump next shows the incorrect next tag.

 ➔ git tag | grep v83.
v830
v831
v832
v833
v834
v835
v836
v837
v838
v839
 ➔ git bump next
834

The latest tag is v839, but bump is wanting to set v834. Does this not work because it's just a vXXX instead of vX.X.X?

Hi,

Thank you for git-bump! I was searching for versioning best practices and came across your project. So I decided to give it a shot and try it on one of my projects.

Here is what I did:

eldar@eldar-desktop:~/workspace/mybuild-git ─ (git: master) ───────────────────
$ git bump
Appears to be initial release.  Version number required.
eldar@eldar-desktop:~/workspace/mybuild-git ─ (git: master) ───────────────────
$ git bump 0.1
Looks like this is your first release.  Please add the version number to the
work tree (e.g., in your Makefile), stage your changes, and run git bump again.

If this isn't your first release, tag your most recent prior release so that
git bump can find it:

        git tag -s v1.2.3 8675309

OK, that's pretty clear so far.

Edit and stage...

eldar@eldar-desktop:~/workspace/mybuild-git ─ (git: master) ───────────────────
$ git bump 0.1
[master 9e98236] mybuild-git 0.1
 1 file changed, 1 insertion(+), 1 deletion(-)
gpg: skipped "Eldar Abusalimov <[email protected]>": secret key not available
gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag
Error running Git.

Oops. I didn't use GPG before, and I end up having a release commit but no tag created. OK, there's a git bump redo command, may be that's what I want?

eldar@eldar-desktop:~/workspace/mybuild-git ─ (git: master) ───────────────────
$ git bump redo
/var/lib/gems/1.9.1/gems/git-bump-1.0.0/lib/git_bump.rb:226:in `redo': undefined method `sha1' for nil:NilClass (NoMethodError)
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /var/lib/gems/1.9.1/gems/git-bump-1.0.0/lib/git_bump.rb:19:in `start'
    from /var/lib/gems/1.9.1/gems/git-bump-1.0.0/bin/git-bump:7:in `<top (required)>'
    from /usr/local/bin/git-bump:23:in `load'
    from /usr/local/bin/git-bump:23:in `<main>'

I've tried both 1.0.0 ruby gem and a code from master (bf793c1), reproduced on both.

Coin commit hooks that can reside in ./.git/hooks/ that will be called pre and post git bump.

For the pre commit hook if you respect failures you can prevent git bump unless project specific conditions are accounted for. For example all tests must be green before bumping the version.

With the post commit hook you could then do something like publish built gem.

It may also be beneficial to support these hooks in a ./.bump directory so they could be committed and shared with the team.

It would be useful to have something like 'git bump undo/reset/revert' to undo the last version (reset commit, delete tag, etc.) I see thif mainly for experimentation and development purposes, when your history is still local.

It would be nice to be able to install the most recent version from ruby gems, especially since there already were no commits to master for 1 year.

Personally I miss the unsigned tags feature introduced in 8d30b3e.

Thanks in advance!

Hi,

On a couple of packages I use date-based version numbers, e.g. 20220103.2, where the component before the dot is the date of the release and the component after the dot is the 0-based release number on that date.

It would be great if git-bump supported this. Would you be willing to accept a patch for this?

It'd be nice if this allowed to chose between having a v or not in the version

Nowadays the default branch for new GitHub repos is main.

I can see how this could be chalked up to preference, but I'd like to see
better support for prerelase versions. I see two reasonable options for
format:

1. SemVer, which states that

   A pre-release version MAY be denoted by appending a hyphen and a
   series of dot separated identifiers immediately following the
   patch version. Identifiers MUST comprise only ASCII alphanumerics
   and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric
   identifiers MUST NOT include leading zeroes. Pre-release versions
   have a lower precedence than the associated normal version. A
   pre-release version indicates that the version is unstable and
   might not satisfy the intended compatibility requirements as
   denoted by its associated normal version. Examples: 1.0.0-alpha,
   1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

2. RubyGems, which documentation seems to prefer a slightly different
   format of [major].[minor].[patch].[a-z][numbers]?, but which still
   supports the SemVer version. For what it's worth, Gem::Version would
   parse 1.0.0.alpha1 to 1.0.0.pre.alpha.1 for better sorting, but I
   don't consider that to be a particularly nice option for git-bump's
   pattern.

The current behavior of git-bump when incrementing from, for example,
1.0.0.alpha.1 is to yield 1.0.0.alpha.2, which is reasonable, but
when bumping a specific part of the version the behavior is less
desirable: 2.0.0.0, 1.1.0.0, and 1.0.1.0, respectively, for major,
minor, and point.

A more useful behavior might be to drop the last segment, causing the
afformentioned actions to result in 2.0.0, 1.1.0, and 1.0.1
versions.

My personal preference is to follow the SemVer example of seperating the
"standard" major/minor/patch versions from the prerelease versions with
a hyphen.

If you're interested, I'm happy to provide a patch to this effect, or to
a format you prefer.

git-bump already provides annotated and signed tags, but to better support
GitHub releases, we could go the extra step to copy the commit message, which
hopefully details highlights of the version change from the previous version.

Unfortunately GitHub don't detect the commit message body (at least when we have
an annotated tag) which means that the Release as created now only includes the
subject from the commit message, which we're using in the tag, for example
"griddler v1.0.0-alpha.1". It's not difficult to add the description from the
bump commit, but it's a step I'd love not to have to take myself.

I'm happy to submit a patch if this behavior is desired.