As we can use 0.x versions for initial development I asked myself how to deal with development versions for a 2.0.0 release?
Originally created by @schmunk42 on GitHub (Jul 1, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/128
As we can use 0.x versions for initial development I asked myself how to deal with development versions for a 2.0.0 release?
I'm still getting used to semantic versioning, so hopefully this will be correct and useful for you… I understand that the 0.x versions are somewhat of a free-for-all since as the spec says, "Anything may change at any time."
Once you're planning a 2.0.0 release, you can no longer use full version numbers (x.y.z) for unreleaseable versions. So my understanding is you'd use something like these version/build examples, adapted from sections 9 and 10 of the spec:
2.0.0-alpha
2.0.0-alpha.1
2.0.0-0.3.7
2.0.0-x.7.z.92
2.0.0-beta+exp.sha.5114f85
…or whatever fits your development process.
<!-- gh-comment-id:20309987 -->
@ericdobson commented on GitHub (Jul 1, 2013):
I'm still getting used to semantic versioning, so hopefully this will be correct and useful for you… I understand that the 0.x versions are somewhat of a free-for-all since as the spec says, "Anything may change at any time."
Once you're planning a 2.0.0 release, you can no longer use full version numbers (x.y.z) for unreleaseable versions. So my understanding is you'd use something like these version/build examples, adapted from sections 9 and 10 of the spec:
- 2.0.0-alpha
- 2.0.0-alpha.1
- 2.0.0-0.3.7
- 2.0.0-x.7.z.92
- 2.0.0-beta+exp.sha.5114f85
…or whatever fits your development process.
Exactly what @EricDobson said. The pre-release identifier can be anything you want it to be. One common approach is to go through alphabeta and rc releases where rc == release candidate. Then when you're ready to release your RTM of 2.0.0, you just remove the pre-release portion of the version.
Example of one possible release schedule:
2.0.0-alpha.1
2.0.0-alpha.2
2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0-rc
2.0.0
<!-- gh-comment-id:20379630 -->
@haacked commented on GitHub (Jul 2, 2013):
Exactly what @EricDobson said. The pre-release identifier can be anything you want it to be. One common approach is to go through `alpha` `beta` and `rc` releases where `rc` == `release candidate`. Then when you're ready to release your RTM of `2.0.0`, you just remove the pre-release portion of the version.
Example of one possible release schedule:
- `2.0.0-alpha.1`
- `2.0.0-alpha.2`
- `2.0.0-beta.1`
- `2.0.0-beta.2`
- `2.0.0-beta.3`
- `2.0.0-rc`
- `2.0.0`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @schmunk42 on GitHub (Jul 1, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/128
As we can use 0.x versions for initial development I asked myself how to deal with development versions for a 2.0.0 release?
@ericdobson commented on GitHub (Jul 1, 2013):
I'm still getting used to semantic versioning, so hopefully this will be correct and useful for you… I understand that the 0.x versions are somewhat of a free-for-all since as the spec says, "Anything may change at any time."
Once you're planning a 2.0.0 release, you can no longer use full version numbers (x.y.z) for unreleaseable versions. So my understanding is you'd use something like these version/build examples, adapted from sections 9 and 10 of the spec:
…or whatever fits your development process.
@haacked commented on GitHub (Jul 2, 2013):
Exactly what @EricDobson said. The pre-release identifier can be anything you want it to be. One common approach is to go through
alphabetaandrcreleases whererc==release candidate. Then when you're ready to release your RTM of2.0.0, you just remove the pre-release portion of the version.Example of one possible release schedule:
2.0.0-alpha.12.0.0-alpha.22.0.0-beta.12.0.0-beta.22.0.0-beta.32.0.0-rc2.0.0@schmunk42 commented on GitHub (Jul 2, 2013):
Thanks to both of you.