When should a commit not be version tagged?
Context: I recently found out about Semantic Versioning, and am trying to determine how to best use it practically for my own projects.
Given that semver takes major changes, minor changes, and patches into account for versioning, when should a commit not be tagged with an updated version? It seems to me that every change would fit into one of these categories, and so every change should be versioned, but when I look at various popular projects on GitHub this doesn't seem to be the way things are done (just looking at the fact that large projects have tens of thousands of commits, with only hundreds of tags).
programming-practices git semantic-versioning tagging
asked 3 hours ago
VortixDevVortixDev
1345
add a comment |
Context: I recently found out about Semantic Versioning, and am trying to determine how to best use it practically for my own projects.
Given that semver takes major changes, minor changes, and patches into account for versioning, when should a commit not be tagged with an updated version? It seems to me that every change would fit into one of these categories, and so every change should be versioned, but when I look at various popular projects on GitHub this doesn't seem to be the way things are done (just looking at the fact that large projects have tens of thousands of commits, with only hundreds of tags).
programming-practices git semantic-versioning tagging
asked 3 hours ago
VortixDevVortixDev
1345
6
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago
add a comment |
Context: I recently found out about Semantic Versioning, and am trying to determine how to best use it practically for my own projects.
Given that semver takes major changes, minor changes, and patches into account for versioning, when should a commit not be tagged with an updated version? It seems to me that every change would fit into one of these categories, and so every change should be versioned, but when I look at various popular projects on GitHub this doesn't seem to be the way things are done (just looking at the fact that large projects have tens of thousands of commits, with only hundreds of tags).
programming-practices git semantic-versioning tagging
asked 3 hours ago
VortixDevVortixDev
1345
Context: I recently found out about Semantic Versioning, and am trying to determine how to best use it practically for my own projects.
Given that semver takes major changes, minor changes, and patches into account for versioning, when should a commit not be tagged with an updated version? It seems to me that every change would fit into one of these categories, and so every change should be versioned, but when I look at various popular projects on GitHub this doesn't seem to be the way things are done (just looking at the fact that large projects have tens of thousands of commits, with only hundreds of tags).
programming-practices git semantic-versioning tagging
programming-practices git semantic-versioning tagging
asked 3 hours ago
VortixDevVortixDev
1345
asked 3 hours ago
VortixDevVortixDev
1345
edited 3 hours ago
VortixDev
asked 3 hours ago
VortixDevVortixDev
1345
asked 3 hours ago
VortixDevVortixDev
1345
asked 3 hours ago
VortixDevVortixDev
1345
1345
6
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago
add a comment |
6
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago
6
6
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago
add a comment |
2 Answers
2
active
oldest
votes
SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.
Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
|
show 1 more comment
Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.
Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.
Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.
A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.
Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.
answered 1 hour ago
Peter GreenPeter Green
1,579512
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f388034%2fwhen-should-a-commit-not-be-version-tagged%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.
Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
|
show 1 more comment
SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.
Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
|
show 1 more comment
SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.
Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change.
Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do so, they will tag according to their versioning scheme, which doesn't necessarily have to be SemVer in particular.
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
answered 3 hours ago
Alex ReinkingAlex Reinking
1,179315
1,179315
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
|
show 1 more comment
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
1
1
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
SemVer mostly only makes sense for libraries where the user is other bits of code and not humans. There aren't really any "breaking" changes in most user facing apps because the user can automatically adapt to the new version.
– Qwertie
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
I would argue that command line versions of user facing apps should be semantically versioned since their flags and output formats can behave differently. Bit of a grey area.
– Alex Reinking
1 hour ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@Qwertie User expectations are less rigid than software expectations but they do still exist. I have DEFINITELY used many pieces of software that have issued what I would consider 'breaking' changes to their interface or functionality. Deciding what constitutes a major vs. minor release is certainly more subjective than with libraries, but that's not necessarily a reason to avoid it.
– Iron Gremlin
47 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@IronGremlin Seeing a major version change in a library is a message to a developer that they need to read a change log to see if they use anything that was changed and to do extra testing. What is a user expected to do when they see a major version change? Prepare to write angry emails?
– Qwertie
43 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
@Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
– Alex Reinking
40 mins ago
|
show 1 more comment
Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.
Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.
Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.
A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.
Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.
answered 1 hour ago
Peter GreenPeter Green
1,579512
add a comment |
Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.
Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.
Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.
A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.
Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.
answered 1 hour ago
Peter GreenPeter Green
1,579512
add a comment |
Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.
Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.
Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.
A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.
Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.
answered 1 hour ago
Peter GreenPeter Green
1,579512
Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this.
Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be hardware or configuration specific, some issues may be more about human-subjective considerations than about hard testable requirements.
Secondly bumping the major version number should be a rare action. It basically means that everything that depends on your software needs to be manually checked to see if it depends on any of the removed features.
A consequence of this is you should only add features to your "public API" in full (not alpha/beta) releases if you are prepared to support those features in their present form long-term.
Thirdly it's helpful to keep the number of versions in widespread use down. Even on a stable branch it is often better to gather a number of fixes together and make a single release than to make a release for every fix.
answered 1 hour ago
Peter GreenPeter Green
1,579512
answered 1 hour ago
Peter GreenPeter Green
1,579512
answered 1 hour ago
Peter GreenPeter Green
1,579512
answered 1 hour ago
Peter GreenPeter Green
1,579512
1,579512
add a comment |
add a comment |
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f388034%2fwhen-should-a-commit-not-be-version-tagged%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
Is every commit to master a stable, tested, quality assured release in your project?
– Alex Reinking
3 hours ago
@AlexReinking Every commit is tested, but I'm just trying to get accustomed to common practices with my personal projects, so it's just me working it and as such there isn't really a system in place other than "make a change, test it myself, commit it".
– VortixDev
3 hours ago