[GH-ISSUE #128] How to deal with development versions after 1.0.0? #1815

New Issue

GiteaMirror · 2026-04-20T09:26:29-05:00

GiteaMirror commented

2026-04-20 09:26:29 -05:00

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?

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?

GiteaMirror closed this issue

2026-04-20 09:26:30 -05:00

GiteaMirror commented

2026-04-20 09:26:31 -05:00

@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.

@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.

GiteaMirror commented

2026-04-20 09:26:32 -05:00

@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

@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`

GiteaMirror commented

2026-04-20 09:26:33 -05:00

@schmunk42 commented on GitHub (Jul 2, 2013):

Thanks to both of you.

@schmunk42 commented on GitHub (Jul 2, 2013): Thanks to both of you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1815