[Edited: A quick answer could be the terms to google maybe? When I google 'linux "C++" version' I don't get many if any, useful links.]

I am not terribly new to programming under Linux, but I am new to "doing it right". What I mean by that, is that I am a scientist/engineer type who writes code to perform basic research, but now find myself in need of providing code to others. Therefore, I would like to know how to do some things, that I have not been "doing right".

The first question(s) have to do with release versions, or build versions, etc.

When my boss ask me which version of the code we were testing, all I can say is, "The latest one". When he asked which version such and such occurred with, all I could say was "The previous/other one." I can't say version 1, or 2, etc. much less. 1.2.1-590.

I am curious how one tracks things like this. For example my current kernel is 2.6.25.11-60.fc8. Is the version # tracked in svn? Do you tag it and then branch etc? I don't currently do all this, in fact, (By the way, what does -60 indicate? A build version of 2.6.25.11?

Is there a way to embed this information into a shared library or executable? Any and all help on this would be GREATLY appreciated. Links to articles are great too... I wouldn't mind at all being told... "read this, don't come back until you do".


Next, when I provide my code to someone, should I provide a script to "install" the libs? If so, where should they go? I currently copy the lib I am working on to /lib64 on my FC8 machine? Where does one generally want to place libs/executables when they are distributed?

Thanks,
CB

I am not an expert, but it sounds like you are somewhat familiar with source version control if you are aware of svn. But you have the basic idea that having code in version control allows you to track your versions.

So I think the minimum you should do is:
1. Put your code into a version control system
2. The code can also include the scripts you use to generate the installable version (like a Makefile).
3. When you are happy with your code (doing whatever testing you want), you can tag it to save the version.

If you want your code to have a version number, I suggest you put a compilable string into your code, e.g. #DEFINE SW_VERSION "1.3.5"
where you can use whatever format you like. Then somewhere add a function to printf ("VERSION: %s",SW_VERSION);

Basically, you would update this version string before a release. However, it can be easy to forget to update it in your source code before you tag your code.

Sorry if I haven't answered any of your direct questions, like the Linux version numbering, or the install method. I am not knowledgeable about those things.

There's no standard version-numbering scheme, but it should be readily apparent how "serious" the changes are from one version to the next. Normally source changes that don't overtly change the behavior of the code (i.e. they refine it or debug it instead) would cause a change toward the end of the version number, e.g. from 1.1.0 to 1.1.1. An interface change such as the removal or modification of a function's declaration would cause a change somewhere earlier in the version number, e.g. 1.1.0 to 1.2.0. This serves as a visual indication that code developed with the old library might require some modification to work with the new one. A complete overhaul, such as a change in naming conventions, would be the most significant of all changes, thereby changing the left-most portion of the version, e.g. 1.1.0 to 2.0.0.

Above is a general pattern many developers use, though some systems are quite a bit more complex and denote parallelisms in versions. The kernel, for example, uses a version with an odd-valued second number (e.g. 2.5.x) to denote that it's experimental, then changes that number to even (e.g. 2.6.x) when it's stable, but concurrently maintains two separate versions at one time: one stable and one experimental.

You can make the version available to the using programs by using a global extern const char* that's defined within the source of your library, or you can create a macro in a header that the using programs will include. I find that both is the best thing to do.

Some systems use a set of independent numbers that aren't necessarily in the order of their importance. For example, a library might use x.y.z where x is the interface version, y is the source code version, and z is the build version.

It really just depends on what you want to communicate to your users through the version number alone. You want to be able to answer the most frequent and simple questions through the use of a logical and consistent numbering scheme. The most obvious questions I'd want answered are:

• Can I use it with my previously-linked binary code?
• If not, can I just recompile the old code with the new headers to incorporate the changes?
• Should I even bother upgrading from version x?
• Will I spend numerous hours making changes to my existing code?

Your users might have been asking about the state of the code, such as alpha, beta, release, etc. These terms should be used as an indication of how much the user should count on any given version. For example, I "reserve the right" to make any and all changes to interfaces and behaviors from one alpha version to the next because I haven't yet figured out how best to implement everything. Beta versions are a bit more stable, but are still susceptible to a complete rewrite when the release version comes along.

ta0kira