0

Following the SemVer guidelines with x.y.z, I know I should start my developments with version 0.1.0 and do the following in case of:

  • Breaking change: increment y instead of x (which shall remain to 0 until the first production release).
  • Feature: ???
  • Patch: increment z.

As the question marks suggest, should I increment y or z when adding a new feature to my unreleased app?

ttous
  • 336
  • 1
  • 3
  • 12

1 Answers1

0

The SemVer specification gives these instructions:

  1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. [...]
  2. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. [...]
  3. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. [...]

So basically, Z is incremented for fixes, Y is incremented for features, X is incremented for breaking changes whether they're about features or fixes.

While in the initial developments phase, we just don't deal with the breaking change part because we have no production users. Therefore, we should increment Z for fixes, and Y for features, no matter if the changes are backwards compatible or not.

ttous
  • 336
  • 1
  • 3
  • 12