Minor version Y MUST be incremented if any non backwards compatible changes are introduced.

This gives special rules to minor level in the context of major zero. That doesn't really seem like the best idea. Consistency is key, and that means incompatible changes == major version bump.

@krainboltgreene I understand your point. But it seems to be rather widely understood that versions below 1.x are special and are undergoing rapid changes that are incompatible. It would seem counter-intuitive to me if an app/lib became stable at v85.x, but perfectly intuitive if it were v1.x.

Incrementing the major version every time an incompatible change is introduced would cause a massive increase in the versions. It also decreases the importance to that major version, making it seem, well, minor.

Stability is a horizon. Your library doesn't become stable, you just reach a point where you think all the problematic bugs are solved. There will still be instability and changes as long as you're working on a library.

1.0.0 doesn't mean stability, it just means the current public API represented in a fixed value.

The word "stable" obviously has some caveats, and the exact meaning need not be discussed into oblivion. I don't think it's necessary nor wise to nitpick the meanings of each word.

In the minds of the developers, there is a point at which the believe their application and/or library has become "stable." The attached change (ea454b6) seems to convey this information appropriately.

Your suggestion to not apply significant meaning to 0.y.z means there is no significant meaning to the initial development stage. Doing so would be detrimental to developers and end users, as it would be far more difficult to determine a point at which software becomes stable.

@krainboltgreene Would you then propose to remove any special designation for 0.y.z altogether?

I would support such approach.

Is this really needed? I'd like to weigh every addition to the spec with the value the addition brings. Does this bring a lot of value in contrast to the extra complexity?

Right now, I'm not convinced.

Currently the versions prior to 1.0.0 don't have any significant meaning for semver and can practically be ignored (are not of any use in semver).

V1.0.0 doesn't mean the library is stable, it means the library's API is stable. It doesn't have anything to do with bugginess.

I would just drop the context of "stability" from the conversation. Releasing any major version just denotes a public API that is going to exist and behave at least this way, regardless of fixes or improvements.

@krainboltgreene A major version X where X > 0 means a stable API. A major version where X = 0 means an WIP/in-development API.

All releases are works in progress. All releases are in-development.

On Tue, Jul 1, 2014 at 4:15 AM, Miles Rout [email protected] wrote:

@krainboltgreene https://github.com/krainboltgreene A major version X
where X > 0 means a stable API. A major version where X = 0 means an
WIP/in-development API.

—
Reply to this email directly or view it on GitHub
#195 (comment).

Kurtis Rainbolt-Greene, Hacker
Software Developer
1631 8th St.
New Orleans, LA
70115

WIP/in-development _API_, I said.

I disagree that all releases are works in progress, and that all releases are in-development. In a perfect world, this might be the case. But in reality, something that is released might not have any further work done on it: this might be due to lack of developers, movement to a new project that supersedes the old one, or a myriad of other possibilities.

Semver's purpose is to ease the "dependency hell" that some developers (albeit not me) are in. It's a way to communicate when your public releases introduce changes to the API.

However, for 0.x.y versions semver proposes (or should at least) to just not brainlessly depend on version ranges because version changes in that state are not clearly defined, so you practically have to check each version manually for backwards incompatible changes that could break the dependency for you. Restricting 0.x.y releases to the proposed format (which is basically shifting major and minor down by 1 level and combining minor and patch) would solve that.

I'm kinda neutral on this, but the spec should probably state what I said more explicitly. Meaning: You may depend on versions prior to 1.0.0 but you may not expect to depend on future versions in the same way as for versions >=1.0.0.

I'm -1 on this addition. Rule 1 states that "Software using Semantic Versioning MUST declare a public API". The rest of the spec defines how version components change with regard to that public API. Rule 4 carves out special treatment of 0.y.z versions to give developers time to establish the public API that then allows for intelligent incrementing of the version number. So when you say "Minor version Y MUST be incremented if any non backwards compatible changes are introduced" then I have to ask, backwards incompatible compared to what? It would be a huge burden for new projects to define that, and Semver succeeds when it's easy to adopt. If a project is at the stage where it's tracking the compatibility of changes (perhaps because it has a ton of users), then it should already be on major version 1.