[GH-ISSUE #245] Nightly Builds #2885

New Issue

GiteaMirror · 2026-04-25T17:00:14-05:00

GiteaMirror commented

2026-04-25 17:00:14 -05:00

Originally created by @coreyavis on GitHub (Feb 19, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/245

I didn't see any information on how nightly builds should be denoted.

Originally created by @coreyavis on GitHub (Feb 19, 2015). Original GitHub issue: https://github.com/semver/semver/issues/245 I didn't see any information on how nightly builds should be denoted.

GiteaMirror closed this issue

2026-04-25 17:00:14 -05:00

GiteaMirror commented

2026-04-25 17:00:15 -05:00

@FichteFoll commented on GitHub (Feb 19, 2015):

See discussion in #200 and similar issues.

@FichteFoll commented on GitHub (Feb 19, 2015): See discussion in #200 and similar issues.

GiteaMirror commented

2026-04-25 17:00:16 -05:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@coreyavis, I have managed to handle this several different ways over the years. My best advice is to append a -prerelease tag of some kind on all nightly builds, plus a build metadata tag. A common practice looks something like:

ProductName.0.0.patch-a.nightly+BranchName.MachineName.

Always bump the patch number and pin the major and minor numbers to zero. You can optionally encode version provenance in the BranchName or append two or three dot separated numbers to build meta-data.

Other options:

ProductName.BranchName.Nightly.semver_string
Nightly.BranchName.ProductName.semver_string

The point here is that night build processes are an internal thing and there would normally be an additional release step that selects a tested build, signs and packages it, so nightlies really aren't within the scope of the standard. Just apply the standard to your processes in whatever ways seem most sane for you organization.

Unless you have any further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @coreyavis, I have managed to handle this several different ways over the years. My best advice is to append a -prerelease tag of some kind on all nightly builds, plus a build metadata tag. A common practice looks something like: ProductName.0.0.patch-a.nightly+BranchName.MachineName.<commit hash> Always bump the patch number and pin the major and minor numbers to zero. You can optionally encode version provenance in the BranchName or append two or three dot separated numbers to build meta-data. Other options: ProductName.BranchName.Nightly.semver_string Nightly.BranchName.ProductName.semver_string The point here is that night build processes are an internal thing and there would normally be an additional release step that selects a tested build, signs and packages it, so nightlies really aren't within the scope of the standard. Just apply the standard to your processes in whatever ways seem most sane for you organization. Unless you have any further questions, please close this issue at your earliest possible convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2885