Continuous (single-digit) versioning

Describe the bug

v0 + major bump = null 💥

To Reproduce

• latest (and the only) git (annotated) tag is v0
• default release type is major to always increment the first digit
• running auto latest --dry-run:

✔ Latest Release:  v0 (...​)
...
✔  success   Calculated SEMVER bump: major
ℹ  info      Would have created a release on GitHub for version: null

Expected behavior

v0 + major bump = v1

(or generally vN + major bump = v(N+1))

Environment information:

Redacted (private repo):

Environment Information:

"auto" version: v10.20.0
"git"  version: v2.30.2
"node" version: v12.18.1

Project Information:

...
✔ Current Version: v0
✔ Latest Release:  v0 (​https://github.com/.../releases/tag/v0​)

✔ Labels configured on GitHub project 

Standalone Auto installation (non-npm project). Plugins:

{
  "plugins": [
    [
      "docker",
      {
        "registry": "...",
        "image": "..."
      }
    ],
    "released"
  ],
  "shipit": {
    "noChangelog": true
  },
  "latest": {
    "noChangelog": true
  },
  "canary": {
    "force": true
  },
  "labels": [
    {
      "name": "release",
      "changelogTitle": "🚀 Enhancement",
      "description": "Any change, feature or enhancement",
      "releaseType": "major",
      "default": true
    },
    {
      "name": "no-release",
      "changelogTitle": "🏠 Internal",
      "description": "Changes that don't touch user-facing code",
      "releaseType": "none"
    }
  ]
}

Additional context

I’m not sure if this behavior is meant to supported, but I’m filing it as a bug because null is never a valid answer 😄

[laughedelic]

How about setting “default: true” on the major label? Then auto would only ever do major bumps and your version would always be something like 1.0.0. Does that work for you?

Yes, this is what we are using at the moment, but it’s definitely not the same.

Would you be open to generalizing the way versions are treated in the code? For example, if version is a template, like ${major}.${minor}.${patch} (pseudo-syntax) for SemVer and all version transformations in the code use that template, then this template could be configurable and set to ${major} or ${major}.${minor} or even something more interesting like ${year}.${month}.${patch} (CalVer of sorts).

[JReinhold]

Would you be open to generalizing the way versions are treated in the code? For example, if version is a template, like ${major}.${minor}.${patch} (pseudo-syntax) for SemVer and all version transformations in the code use that template, then this template could be configurable and set to ${major} or ${major}.${minor} or even something more interesting like ${year}.${month}.${patch} (CalVer of sorts).

Yeah this would be a great addition. We’re starting to use auto to release applications, and in those scenarios semver rarely makes sense (when is a change “breaking” or “minor” in an application?). We want to use something like ${year}.${month}.${patch} as that is more human-readable.

It could also just be a plugin release hook that allowed you to override the calculated version that auto uses throughout the pipeline. At first I thought that was what the version hook did, but from the docs it doesn’t seem like we’re able to return a version number, only act on it?