Next Semantic Version¶
nsv core principles of being context-aware and convention-based will let you achieve almost all of your semantic versioning needs when running:
By scanning all commit messages within the latest release, nsv understands the author's intent and prints the next semantic version to stdout.
If you want to see what is happening under the hood:
0.2.0
┌───────────────┬──────────────────────────────────────────────────┐
│ 0.2.0 │ > e0ba951 │
│ ↑↑ │ docs: document new exciting feature │
│ 0.1.0 │ │
│ │ ✓ 2020953 │
│ │ >>feat<<: a new exciting feature │
│ │ │
│ │ > 709a467 │
│ │ ci: add github workflows │
└───────────────┴──────────────────────────────────────────────────┘
If you need to customize its behavior, environment variables, CLI flags, or commands can be used.
Configurable paths for monorepo support¶
Monorepo support is important to the design of nsv. By adding support for context paths, multiple semantic versions can be resolved throughout a repository in a single operation.
Any version change will be printed to stdout as a comma separated list in context path order:
Version template customization¶
Internally, nsv utilizes a go template when constructing the next semantic version:
Runtime customization of this template is available. For example, you can enforce explicit semantic version usage:
Or you could enforce a prefix on all of your tags:
Tag prefixes are used by nsv when scanning for previous versions
This is incredibly helpful if you want to maintain multiple tags within a monorepo, as each tag will be versioned independently.