Semi-automatic version numbering with git

Walking through github I have seen many times in different repositories simultaneously tags like “v2.3.4” and commits with messages like “Bump version” and changing the version numbers somewhere in lib / version.rb. And it always seemed to me that something was superfluous.

And when it came time to think about the distribution of version numbers to me, I said: “No! I will not register these numbers in the files by hand. Let my version control system do it for me! ”

So, as I see it:

1. The version number looks like a triple of numbers: the major.minor.patch version and is increased according to the rational version assignment policy ;
2. When releasing each new minor version, I create a tag of the form v <major>. <Minor> for a certain commit in history;
3. Git automatically gives me the version number, based on the last tag (for this commit) and the number of commits after it.

How it works:

As part of git there are many useful commands, we will be interested in two:

1. git describe - shows information about the latest tag available from this commit;
2. git show - displays various types of objects (but we will be interested only in the current commit).

')
Armed with this knowledge, I put the version.rb file in my rails project in the config / initializers folder as follows:

 module AppName module Version Described = (IO::popen('git describe --long') { |gs| gs.read }).strip Number = Described.gsub('-', '.').gsub(/^v/, '').split('.')[0..-2].join('.') Date = Date.strptime( IO::popen('git show -s --format="%ct"') { |gs| gs.read } , "%s") Revision = (IO::popen('git show -s --format="%H"') { |gs| gs.read }).strip end end 

Here the following happens:

The git describe --long displays a message similar to the following: v0.8-3-g387f83f , where

• v0.8 - tag name
• 3 - the number of commits after this tag (0 if the tag is set for the current commit)
• 387f83f - short hash of the current commit.

The line Described.gsub('-', '.').gsub(/^v/, '').split('.')[0..-2].join('.') Leads this message to the form 0.8.3

Using the git show -s --format="%ct" command git show -s --format="%ct" we get the date for creating the current commit in Unix format.

And git show -s --format="%H" returns us the full hash of the commit.

Result

Now at the start of the application, the current version number and release date are automatically available to us. And now, somewhere on the page we can write:

 " AppName.  #{AppName::Version::Number}  #{I18n.l AppName::Version::Date, :format => :long} ." 

And to get

 " AppName.  0.8.3  27  2012 ." 

Advantages and disadvantages

pros

• Soaring over the version numbers is now less, and the cases “Ah, damn, forgot to increase the version number!” Will now be less frequent (after all, the minor and major versions do not come out every day, right?);
• (As a result of the previous paragraph) The potential incompatibility of version numbers in the repository and in the code is eliminated (there are no more in the code);
• Ideal for compiled programs (C ++), as part of the build process.

Minuses

• Outside the repository will not work (and who and why was going to keep the code outside the repository?);
• Hard binding of the number of commits to the patch version number (on the other hand, do not commit to each line of code);
• Sometimes the version number must still be hard coded;
• Not suitable for, for example, PHP, since calling a couple of three shell commands for each request is expensive.

What to read?

Well, first of all, manuals for git describe and git show .

In general, a search on "<CVS> autoversioning" (where <CVS> is the name of your favorite version control system) will give you a considerable amount of recipes for any cases, programs and technologies.

Good luck to you in establishing order (at least in versions).