some thoughts after using svu for a while, maybe some ideas for improvement

[sheldonhull]

I have to do a bit of wrapper logic to confidently use this right now. I have a few ideas maybe they will be useful. This comes from running the app in the prior version for years in production releases, having just adapted to the latest version, and also having used changie as my default tool for most cases now.

As I mentioned on twitter, one app I setup has had over 1300+ releases using svu for tagging 🎉.

Here's some quick thoughts, and maybe this won't align with what you want from SVU, which is fine.
I tend to want something like svu to do the actual tagging and such, but I understand you want it to be more of a tool to call in scripts than standlone.

Why I'd choose changie:

• First class release communication
• Stop worrying about adherence to conventional commit as a requirement to actually version.
• Control the version increment based on type much more explicitly.
• All my projects default to using this if they are not throwaway right now.

Why I'd choose svu:

• Internal tools I don't need to communicate releases on, such as gitops pushes.
• Low overhead for monorepo prefixed tag logic to be processed.

So here's a few thoughts:

---

• Allow mapping the conventional commit types and version bump.

Example 1:

kinds:
  - label: ✨ New
    key: new
    auto: minor
  - label: 🪄 Improved
    key: improved
    auto: minor
  - label: 🐛 Fixed
    key: fixed
    auto: patch
  - label: 🔥 Breaking Change
    key: breaking-change
    auto: major
  - label: ⬆️ Dependencies
    key: dependencies
    auto: patch

However, in another project (group of repo), I can be more explicit to ensure that contributors don't have to think about my versioning policy, but instead just pick the right type and it maps to the right incrementing version.

Since a feature for a build script, github actions, etc is probably not the same as a feature in the app source code, this keeps the cognitive load down.

  - label: ✨ Terraform New Feature
    key: new-feature
    auto: minor
  - label: 🔨 Terraform Parameter Change (Optional)
    key: parameter-change-optional
    auto: minor
  - label: 🔥 Terraform Parameter Change (Required)
    key: parameter-change-required
    auto: major

Calendar Versioning

💡 If I'm doing a release constantly, instead of always incrementing patch, maybe the scheme could be calver supported for those. This would bring some nice value to using svu.

Missing Flags

I've had to do my own mage processing/wrapper to be able to work with:

• prefixed tag
• prefixed tag without prefix
• prefixed tag without prefix but with v (as the v is not a prefix to me when dealing with the actual tag). You know as well that in Go, v is required for versioning, however, to compare versions returning with certain libraries or tools, the version without the prefix is expected. Having option to strip prefix and/or the v is important to cut down other post processing work.

[caarlos0]

hey, I see your points, and I had thought about some of them myself, but ultimately decided I don't need them.

I think if someone wants to contribute the config stuff, I'd be happy to, but right now not sure I'll work on it.

For the flags, if I understand correctly, I think you can:

1. svu c for current tag
2. svu c --prefix='' for current tag without prefix
3. I think we might need to add a new option, maybe something like --tag.output.prefix? so users could: svu c --tag.pattern='cellbuf/v*' --tag.prefix='cellbuf/v' --tag.output.prefix='v'. maybe even clarify between tag.input.prefix and tag.output.prefix, with tag.prefix being an alias for both of them 🤔