Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

non-existence may be a bug #81

Closed
wants to merge 1 commit into from

3 participants

@ymendel

0.0.x versions are troublesome. Turns out one of them might be considered to make some sort of sense.

@dgn1nja

This creates a precedent for implying semantic versions, which isn't really the point of SemVer; versions should be explicitly stated.

0.0.x releases aren't explicitly banned in the spec. Rather, in the FAQ, it's just suggested that the first release be versioned 0.1.0, implying that the initial internal development is done under versions 0.0.x.

If a version is missing from a versioned library, then yes, it is a bug, but there should be no implied version for that release. Instead, a patch for the library should be released as soon as possible rectifying the situation by adding the missing version with an incremented patch number as well. Notifying users of the broken release would probably be a good idea too.

@ymendel

I'm not sure what you're saying when you say this implies semantic versions and that isn't really the point.

The spec clearly states that the patch version is for bug fixes and the minor version is for new functionality. What bugs are there without functionality?

Maybe the spec or FAQ should be clearer about how and why it makes sense to start at 0.1.0 and that 0.0.6 should not exist.

@Haacked
Collaborator

I thought you were just kidding!

Regarding the FAQ, I assume you're talking about this one?

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

The way I read that is it's just a suggestion. The FAQ doesn't override the spec rule 5:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Given that anything can change at any time, changing Minor or Patch version for a 0.* version doesn't have any real meaning other than to indicate a newer version. It can be used to communicate intent, but that's about it.

So I don't think the spec needs to dictate how 0.* versions are incremented. I think incrementing minor versions is a sane approach, but it doesn't need to be required.

@ymendel

Am I kidding? Did this come out of conversation with Tom on Friday? You'll never know. Or maybe you might.

I'm a bit torn on things being so different before and after the 1.0 cliff. Really, it just makes me wonder if I should ever use anything that's pre-1.0.

@Haacked
Collaborator

I'm closing this as an epic :trollface: If I closed it in error, feel free to reopen. Well played sir. Well played.

@Haacked Haacked closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 16, 2013
  1. @ymendel

    non-existence may be a bug

    ymendel authored
This page is out of date. Refresh to see the latest.
Showing with 4 additions and 0 deletions.
  1. +4 −0 semver.md
View
4 semver.md
@@ -73,6 +73,10 @@ incompatible changes are introduced to the public API. It MAY include minor
and patch level changes. Patch and minor version MUST be reset to 0 when major
version is incremented.
+1. Non-existence MAY be considered a bug, which allows for an initial version
+of 0.0.1. However, the next version would introduce new functionality and MUST
+increment the minor version.
+
1. A pre-release version MAY be denoted by appending a hyphen and a series of
dot separated identifiers immediately following the patch version. Identifiers
MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Pre-release
Something went wrong with that request. Please try again.