[GH-ISSUE #252] Do I version on every pull request/commit or per Release #1909

New Issue

GiteaMirror · 2026-04-20T09:43:08-05:00

GiteaMirror commented

2026-04-20 09:43:08 -05:00

Originally created by @PatrickWalker on GitHub (May 7, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/252

As a package maintainer I may be in a position where a number of pull requests come in close together.

My current version of the project is 2.5.0 so now I have 3 new backwardly compatible features available before I'm scheduled to release (let's say I have a cadence)

Do I go

2.5.0 -> 2.6.0 -> 2.7.0 -> 2.8.0

and in essence rev the version every-time I merge in a pull request? That way each time new functionality has been added the version has shown that or do I allow myself to plan a release of an aggregate of functionality and rev to 2.6.0 using RC build numbers that increment per pull request I merge in?

Basically do I version everytime a commit makes a change to the API or do I allow myself to batch a number of equal or less affecting changes into 1 release (ie my 2.6.0 could contain 2 bug fixes and 4 new backwardly compatible fixes over 2.5.0)

Originally created by @PatrickWalker on GitHub (May 7, 2015). Original GitHub issue: https://github.com/semver/semver/issues/252 As a package maintainer I may be in a position where a number of pull requests come in close together. My current version of the project is 2.5.0 so now I have 3 new backwardly compatible features available before I'm scheduled to release (let's say I have a cadence) Do I go 2.5.0 -> 2.6.0 -> 2.7.0 -> 2.8.0 and in essence rev the version every-time I merge in a pull request? That way each time new functionality has been added the version has shown that or do I allow myself to plan a release of an aggregate of functionality and rev to 2.6.0 using RC build numbers that increment per pull request I merge in? Basically do I version everytime a commit makes a change to the API or do I allow myself to batch a number of equal or less affecting changes into 1 release (ie my 2.6.0 could contain 2 bug fixes and 4 new backwardly compatible fixes over 2.5.0)

GiteaMirror closed this issue

2026-04-20 09:43:08 -05:00

GiteaMirror commented

2026-04-20 09:43:09 -05:00

@dwijnand commented on GitHub (May 7, 2015):

You batch.

SemVer is about defining semantics of the release version, allowing clients
to infer information from the new version. So a 2.6 release means 1-n
backwards-compatible features and/or bugfixes, and 0 incompatible changes.

You can obviously choose to release pre-release versions on every
pull-request. More traditionally nightly builds are done, but I kind of
like your idea more.

On Thu, 7 May 2015 13:04 Patrick Walker notifications@github.com wrote:

As a package maintainer I may be in a position where a number of pull
requests come in close together.

My current version of the project is 2.5.0 so now I have 3 new backwardly
compatible features available before I'm scheduled to release (let's say I
have a cadence)

Do I go

2.5.0 -> 2.6.0 -> 2.7.0 -> 2.8.0

and in essence rev the version every-time I merge in a pull request? That
way each time new functionality has been added the version has shown that
or do I allow myself to plan a release of an aggregate of functionality and
rev to 2.6.0 using RC build numbers that increment per pull request I merge
in?

Basically do I version everytime a commit makes a change to the API or do
I allow myself to batch a number of equal or less affecting changes into 1
release (ie my 2.6.0 could contain 2 bug fixes and 4 new backwardly
compatible fixes over 2.5.0)

—
Reply to this email directly or view it on GitHub
https://github.com/mojombo/semver/issues/252.

@dwijnand commented on GitHub (May 7, 2015): You batch. SemVer is about defining semantics of the release version, allowing clients to infer information from the new version. So a 2.6 release means 1-n backwards-compatible features and/or bugfixes, and 0 incompatible changes. You can obviously choose to release pre-release versions on every pull-request. More traditionally nightly builds are done, but I kind of like your idea more. On Thu, 7 May 2015 13:04 Patrick Walker notifications@github.com wrote: > As a package maintainer I may be in a position where a number of pull > requests come in close together. > > My current version of the project is 2.5.0 so now I have 3 new backwardly > compatible features available before I'm scheduled to release (let's say I > have a cadence) > > Do I go > > 2.5.0 -> 2.6.0 -> 2.7.0 -> 2.8.0 > > and in essence rev the version every-time I merge in a pull request? That > way each time new functionality has been added the version has shown that > or do I allow myself to plan a release of an aggregate of functionality and > rev to 2.6.0 using RC build numbers that increment per pull request I merge > in? > > Basically do I version everytime a commit makes a change to the API or do > I allow myself to batch a number of equal or less affecting changes into 1 > release (ie my 2.6.0 could contain 2 bug fixes and 4 new backwardly > compatible fixes over 2.5.0) > > — > Reply to this email directly or view it on GitHub > https://github.com/mojombo/semver/issues/252.

GiteaMirror commented

2026-04-20 09:43:10 -05:00

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

@PatrickWalker, the SemVer spec allows you to do it either way. Your own internal workflows should determine which behavior best suits your needs. Do you want to test each change separately or throw them all together first? Will there be A/B flight testing between the different feature sets? It's not up to SemVer to define your internal processes.

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

@jwdonahue commented on GitHub (Dec 8, 2017): @PatrickWalker, the SemVer spec allows you to do it either way. Your own internal workflows should determine which behavior best suits your needs. Do you want to test each change separately or throw them all together first? Will there be A/B flight testing between the different feature sets? It's not up to SemVer to define your internal processes. Unless you have 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#1909