Prefix other than v

[andrewshadura]

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 🙂

[tpope]

Autodetection would be ideal, but the examples you give sound more or less impossible. If there are both upstream/ and debian/ versions on the same repo, how would we know which one the user aims to bump? And dates would dash any hopes of recognizing a simple pattern like 1.2.3.

I could see adding a --tag-prefix=upstream/ option as a low effort first pass. Save the configuration can of worms for another day.

[andrewshadura]

If there are both upstream/ and debian/ versions on the same repo, how would we know which one the user aims to bump?

I’d say the closest one on the current branch. But OTOH debian/upstream thing is more of an example, it’s not a high priority feature to me as Debian-specific tools exist for that already and I’m fine with using them if we can’t make git-bump support that use case 🙂

[andrewshadura]

In fact, thinking about it a bit more, it would be difficult to support bumping Debian packaging since it needs a fresh changelog entry which is difficult to automatically detect and rebase.

[andrewshadura]

I guess what I personally need most is being able to skip v (most of my projects don’t use it) and to use dates as versions (my recent projects use them).

So, how about this:

• If a prefix is configured, consider only tags with said prefix.
• Of all tags considered, find the closest tag to the current HEAD (I need to figure out your what current algorithm with git merge-base does — probably it already does this, but I’m not in the right context right now so I need to think about it later)
• If what seems like the major version is in thousands, try to parse it as a date. If it parses and the year is within the last 20 years, consider the version date-based.

[tpope]

So the only supported date format would be YYYYMMDD.0? Kind of feels like you're adding a special case for you and you alone. Can you cite any prominent projects that use it?

I'm personally not a fan of omitting the v prefix, but this is undoubtedly the second most popular naming convention, and seems very practical to autodetect, if you want to pursue that. Add a second glob to the git for-each-ref call and check for a leading v in latest.tag.

[andrewshadura]

Well, not necessarily the only one, I guess it's possible to detect a couple of other date formats too. Obviously, I'm a bit biased towards this one since I use it 🙂 I'm on a phone right now, so I can't cite many projects using this format but one I can remember is NetBSD make (bmake), but I've seen plenty of others too.

But I guess this discussion it better to happen in the dedicated issue (#10) 🙂

-- Cheers, Andrej