github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-11-13 17:56:10 -06:00
Code Issues 2.1k Packages Projects Releases 4 Wiki Activity

Versioning ci-, nighty-, prerelease-, qa- and staging branches #57

New Issue
Closed
opened 2026-02-17 11:06:54 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-02-17 11:06:54 -06:00
Owner
Copy Link
Copy Source

Originally created by @DoCode on GitHub (Mar 9, 2013).

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

Originally created by @DoCode on GitHub (Mar 9, 2013). 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
GiteaMirror commented 2026-02-17 11:06:56 -06:00
Author
Owner
Copy Link
Copy Source

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

@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.
GiteaMirror commented 2026-02-17 11:06:57 -06:00
Author
Owner
Copy Link
Copy Source

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

@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?
GiteaMirror commented 2026-02-17 11:06:57 -06:00
Author
Owner
Copy Link
Copy Source

@Tieske commented on GitHub (Apr 30, 2013):

imo close

@Tieske commented on GitHub (Apr 30, 2013): imo close
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#57