Ryfujk

Why does the 31P{1H} NMR spectrum of cis-[Mo(CO)2(dppe)2] show two signals?

Non-Italian European mafias in USA?

Called into a meeting and told we are being made redundant (laid off) and "not to share outside". Can I tell my partner?

Auto Insert date into Notepad

It took me a lot of time to make this, pls like. (YouTube Comments #1)

Is divide-by-zero a security vulnerability?

Is my plan for fixing my water heater leak bad?

Why does Starman/Roadster have radial acceleration?

Use comma instead of & in table

Where was Karl Mordo in Infinity War?

Borrowing Characters

Does music exist in Panem? And if so, what kinds of music?

How to speed up a process

What is the wife of a henpecked husband called?

What is better: yes / no radio, or simple checkbox?

Contradiction with Banach Fixed Point Theorem

Are small insurances worth it

Has the Isbell–Freyd criterion ever been used to check that a category is concretisable?

Find the next monthly expiration date

Do authors have to be politically correct in article-writing?

What are these green text/line displays shown during the livestream of Crew Dragon's approach to dock with the ISS?

I encountered my boss during an on-site interview at another company. Should I bring it up when seeing him next time?

How to acknowledge an embarrassing job interview, now that I work directly with the interviewer?

As a new poet, where can I find help from a professional to judge my work?

When should a commit not be version tagged?

7

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

share|improve this question

edited 8 hours ago

VortixDev

asked 8 hours ago

VortixDevVortixDev

1445

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Is every commit to master a stable, tested, quality assured release in your project?
  
  – Alex Reinking
  8 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
  8 hours ago
  

  
  
  
  

add a comment | 

7

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

share|improve this question

edited 8 hours ago

VortixDev

asked 8 hours ago

VortixDevVortixDev

1445

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Is every commit to master a stable, tested, quality assured release in your project?
  
  – Alex Reinking
  8 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
  8 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

share|improve this question

edited 8 hours ago

VortixDev

asked 8 hours ago

VortixDevVortixDev

1445

share|improve this question

edited 8 hours ago

VortixDev

asked 8 hours ago

VortixDevVortixDev

1445

share|improve this question

edited 8 hours ago

VortixDev

asked 8 hours ago

VortixDevVortixDev

1445

asked 8 hours ago

VortixDevVortixDev

1445

asked 8 hours ago

VortixDevVortixDev

1445

2 Answers
2

active

oldest

votes

29

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.

share|improve this answer

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

• 
  
  
  

  
  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
  6 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  5 hours 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
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
  
  – Alex Reinking
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Qwertie They might be inspired to carefully read the change log or documentation so that they can adapt the way that they use the system to make use of new or modified features, or find workarounds for a feature that's been removed. It's the same case, their use of the software needs to change because the software has changed, so you should tell them about that change unambiguously.
  
  – Iron Gremlin
  5 hours ago
  

  
  
  
  

 | 
show 1 more comment

3

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.

share|improve this answer

answered 6 hours ago

Peter GreenPeter Green

1,589512

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
});


}
});

draft saved

draft discarded

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

Name

Email

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

Name

Email

Required, but never shown

29

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.

share|improve this answer

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

• 
  
  
  

  
  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
  6 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  5 hours 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
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
  
  – Alex Reinking
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Qwertie They might be inspired to carefully read the change log or documentation so that they can adapt the way that they use the system to make use of new or modified features, or find workarounds for a feature that's been removed. It's the same case, their use of the software needs to change because the software has changed, so you should tell them about that change unambiguously.
  
  – Iron Gremlin
  5 hours ago
  

  
  
  
  

 | 
show 1 more comment

29

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.

share|improve this answer

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

• 
  
  
  

  
  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
  6 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  5 hours 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
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Qwertie - hold back upgrading. How many people still run old major versions of Windows and Office?
  
  – Alex Reinking
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Qwertie They might be inspired to carefully read the change log or documentation so that they can adapt the way that they use the system to make use of new or modified features, or find workarounds for a feature that's been removed. It's the same case, their use of the software needs to change because the software has changed, so you should tell them about that change unambiguously.
  
  – Iron Gremlin
  5 hours 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.

share|improve this answer

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

share|improve this answer

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

answered 8 hours ago

Alex ReinkingAlex Reinking

1,239515

3

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.

share|improve this answer

answered 6 hours ago

Peter GreenPeter Green

1,589512

add a comment | 

3

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.

share|improve this answer

answered 6 hours ago

Peter GreenPeter Green

1,589512

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.

share|improve this answer

answered 6 hours ago

Peter GreenPeter Green

1,589512

share|improve this answer

answered 6 hours ago

Peter GreenPeter Green

1,589512

answered 6 hours ago

Peter GreenPeter Green

1,589512

answered 6 hours ago

Peter GreenPeter Green

1,589512