Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is good way to maintain versions in a C++ project?

Tags:

c++

We have a C++ project, which has hundreds of SVN revisions every month. Sometimes we need to increment a minor digit in a version number, changing it from, say, 1.6 to 1.7. We do it once per month approximately. What is a correct approach to do it? We want to save/maintain information about changes made in every new version, and we want to have some sort of release notes. Please, give us some suggestions or links. Thanks!

ps. Sorry if the question is too vague.

pps. I see that I need to clarify the question a bit. I'm not interested about how should I name versions. I'm interested how technically I should maintain version numbers in C++ code.

like image 413
yegor256 Avatar asked Jul 15 '10 07:07

yegor256


1 Answers

I use this system for all of the software that I write:

1.2.3.4
  1. The major version number. Only increment on a "major" release that changes numerous product features.
  2. The minor version number. Increment on regular (quarterly, monthly) releases. This number is not limited to 9; feel free to go as high as you need. Don't increment this for minor fixes or updates. When the major version number is changed, this number is set to zero.
  3. The update number. Increment this number whenever you put out a series of updates. An update in my book is considered a release that contains a series of bug fixes, performance improvements, or security enhancements. There must be multiple changes for this to be incremented. This can also be greater than 9. When the minor version number is changed, this is reset to zero.
  4. The minor update number. Increment this with minor, individual changes. For instance, if you fix a specific bug and roll the patch into your last release, this would increase. This number should be reset to zero when the update number changes.

Lastly, I use the following suffixes to denote prerelease builds:

  • b: Beta
  • a: Alpha
  • rc: Release Candidate

Suffixes can be followed by a number to indicate which revision of the prerelease build the package is. For instance:

1.2.3.4b2

would be considered the second beta.

Also, when writing versions, trailing zeros can be eliminated. i.e.: 1.0.0.0 could be written as 1.0.

Hopefully this is somewhat useful. I've found that it helps keep things organized and maintains some semblance of order in my archives.

like image 52
mattbasta Avatar answered Oct 11 '22 01:10

mattbasta