CODEWITHSUNDEEP
c++version-controlprojectversioning
hakuna matata
hakuna matata

Reputation: 3327

maintain version of my c++ project

What is an effective way of maintaining the version of my project?

I started in a project, and I want it to look professional. I want to do a version for my project, like 1.0 or something, but I don't know how to maintain it or from where to start. Is there a criteria for incrementing the version before the decimal or after the decimal point, I think I read somewhere its major or minor changes.

Also, is there an existing software that works on the version of my project automatically depending on the changes I make on my code?

NOTE: I use Code::Blocks

Upvotes: 0

Views: 2207

Answers (2)

Richard Chambers
Richard Chambers

Reputation: 17573

Here is an article that describes the basics of version control Source Code Control

What I do is to have a four field version number. This is made up of the following:

  • Major version number (which seldom changes and only with major changes in functionality)
  • Minor version number (which sometimes changes with large changes in functionality)
  • Issue number which (changes with minor changes in functionality)
  • Build number which is incremented every time I do a build

The purpose of this numbering scheme is so that when there is a field issue, I can determine which version of the source code in my repository was used in the specific build that the field site is having a problem. I can also know what test environment I need to set up so far as files, database, and equipment.

The issue number tends to change when I am making a change in the functionality that may impact database schema in a small way, new parameters being added, new functionality requested for a customer. The Minor version number tends to change when the new functionality or the changes for a customer are significant.

The Major number tends to change only when there is something really earth shattering that means that going from the older major version to the newer major version is a significant upgrade effort. Cases where it has changed was when we moved from Windows CE to Windows XP, an operating system change which required some source changes for that. At the same time we went to UNICODE support for Far East Asian languages as well.

The main thing is to provide some way that when you see the complete version number you can know immediately the major functionality that is there and to know what the version primarily supports and does not support.

When a particular field is incremented, the following fields are reset back to one (1). So when going from Rel 2.2.1 to Rel 2.3.0 the first field stays the same, the second field is incremented, the third field is set to zero, and the fourth field (build number) will start with one for the first build. Then as there is a build of Rel 2.3.0 the fourth field (the build number) will be incremented.

And each time I do a build, I keep the build products (the installers) for that build stored on a server along with the build notes for that build describing the changes made for the build. I also will do a branch in my repository (Subversion) so as to make it easy to find the source code for that build.

Upvotes: 1

Jony Adamit
Jony Adamit

Reputation: 3416


See this for lots of great information about versioning! You didn't mention which development platform you were using, but most of them support auto-incrementing version numbers, but this is only good to signify different builds, rather than a whole new version.

Upvotes: 1

Related Questions