mirror of
https://github.com/semver/semver.git
synced 2026-03-22 14:10:15 -05:00
Major version 0 progression #171
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#171
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MartyBurns on GitHub (Feb 23, 2015).
I often am reaching for a version scheme within the major version 0 -- that is prior to any release. I am aware of a scheme that is something like this:
0.7 -- during initial development
0.8 -- completed draft undergoing review
0.9 final draft for review
1.0 first release version
Does anyone have a better articulation of this concept?
Thanks,
Marty Burns (NIST)
@rabdill commented on GitHub (Feb 28, 2015):
Hi Marty -- I've always started versioning at 0.1, and nothing higher -- I think our difference likely stems from interpretation of point two:
The "for instance" section is what I'm referring to: You're looking at "1.0" as what comes after "0.9," as if the increment above "0.9" must be "1.0." According to best practice, however, the increment after "0.9" is most frequently "0.10," which looks like it should be the same thing as "0.1" but is actually 9 releases ahead of "0.1."
I struggled with this part initially, but eventually got around it by thinking of each version number -- major.minor.patch -- as a separate number, not one decimal number that's being ticked up by tenths through addition.
Anyway, to actually answer your question, I'd start at 0.1.0 and increase minor versions whenever you feel like a logical "bookmark" might fit -- when a major feature is finished, for example, or a complicated refactor is done. I like to make sure I only increment the minor version inside major version 0 when there aren't any half-finished features, but there isn't anything in the spec that says it's the only way to do it.
I switch over to 1.0 whenever the code is reviewed, approved and ready for production. Sometimes that comes after version 0.4, but sometimes it comes after version 0.23. Kerbal Space Program entered their public beta not long ago, and they're on their 90th minor version in major version 0.
Does that help?
@FichteFoll commented on GitHub (Feb 28, 2015):
FWIW, Atom (the text editor) is currently at version
0.184.0(all releases).@MartyBurns commented on GitHub (Feb 28, 2015):
Good couple of comments so far. The atom approach gets over the problem of nudging up to but not getting to 1.0 until it's ready.
The attraction of 0.7, 0.8, 0.9 is that allows for many revisions (timestamps or build number) at each number but preserves the ability to state something about the maturity of the project. For example 0.9 suggest feature complete and near release.
Don't you think that is valuable while you are making frequent release snapshots during development?
Sent from my iPad
@Lucretiel commented on GitHub (Mar 3, 2015):
I like the idea. The big problem is that, if you're at "0.8.x: draft and review," and you introduce new features, the only place you can go is 0.9.y, forcing you to split from the scheme. I ran into this with a library I'm working on, where I was "near release" so I jumped straight from 0.1 to 0.9, but now I'm on 0.11 as I discovered new additions that needed to be made.
@crazedsanity commented on GitHub (Mar 3, 2015):
I don't see why one would feel the need to try jumping to
v0.9.xfrom a version substantially lower (such asv0.1.x). This only seems relevant if a person expects that the minor release version is something like a progress meter (v0.1= 10%,v0.9= 90%), which seems broken.My method is to keep incrementing the version until there's a release candidate. Here's my methodology, updated to (hopefully) the appropriate syntax, where the leading "v" is disregarded:
v0.1.0== first versionv0.1.1== first bugfixv0.2.0== first major changev0.33.18== close to stablev0.33.19-rc.1== first release candidate; maintenance version increased because pre-release identifiers are supposed to be disregardedv0.33.20-rc.2== second release candidate, with some fixes...v1.0.0== full initial release, identical to final release candidate (probablyv0.33.20-rc.2)(I apologize if I've mixed pre-release identifiers with metadata.)
This scheme has no special significance to the minor version number, other than it changes when big changes occur in the pre-1.0 world. Adding the "rc.x" value indicates that this version is in consideration for the next (or the first) full release.
If you want to have a "draft and review" stage, use pre-release terms. Use something like
v0.8.6-dr.1-- which says "version 0.8.6 is ready for draft and review".@FichteFoll commented on GitHub (Mar 3, 2015):
Those two should be release candidates of the 1.0.0 version, so
v1.0.0-rc.1andv1.0.0-rc.2.The way you are proposing is more a resemblance to build metadata, as you mentioned. Which could also work since semver gives you much freedom, but you should use
+instead of-then.@crazedsanity commented on GitHub (Mar 3, 2015):
@FichteFoll thank you for the clarification. What I should have written in my list is more like:
v0.33.18== close to stablev1.0.0-rc.1== copy ofv0.33.18, as a release candidatev1.0.0-rc.2== bugfixesv1.0.0+0.33.18== full release, based onv0.33.18@FichteFoll commented on GitHub (Mar 3, 2015):
Yes, pretty much.
v1.0.0+0.33.18doesn't make much sense to me because0.33.18is the last version before that anyway, but you can do whatever you want with build metadata.@jwdonahue commented on GitHub (Dec 2, 2017):
@MartyBurns , unless you have any further question, can you please close this issue?
@alexandrtovmach commented on GitHub (Jun 10, 2020):
@MartyBurns This issue seems resolved. Feel free to re-open if there still some questions