mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #74] Versioning ci-, nighty-, prerelease-, qa- and staging branches #5174
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5174
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 @DoCode on GitHub (Mar 9, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/74
What's the 'Best-Practices' for this areas?
CI-Builds
1.0.0+beta.1.abcdef.0001
Nightly-Builds
1.0.0+beta.1.abcdef
PreRelease-Builds
1.0.0-beta.1
QA-/Staging-Builds
1.0.0
@haacked commented on GitHub (Mar 13, 2013):
That's a very broad question. I guess the real question is what problems are you running into with your current versioning scheme? Some folks want dates in their build versions while others want the SHA. Under rules proposed in #70 you could do both if you really wanted to as the build metadata is just metadata and doesn't affect the public API version.
@jeffhandley commented on GitHub (Apr 30, 2013):
What you laid out looks reasonable to me.
It will be impossible for version numbers to create "branches" within them. Instead, builds of different types should be placed into repositories that are specialized for only that type of build. That way, for the given build type, only builds of that type exist in the repository and sorting/precedence can always make sense.
Are there any further action items here, or can we close this issue?
@Tieske commented on GitHub (Apr 30, 2013):
imo close