Best practice on code version numbering?

[Tourist Trap]

Hi there,

I'm trying to rationalize my code files names (on disk) appending a version number to them. Until now (in the best case!) I was just appending an incrementing counter. But it's not really talkative. Some time I make also some whole name changing but it can be confusing in the long term. What I would need for instance is something that would tell me for a file what is its status in the developpment history. If a major refactoring has occured, I should see it. Or is it just about small bugs corrections or cosmetics touch of secondary importance (temp files, possibly deletable) ?

Since a while I've noticed that some IDEs are able to append a number each time a build is launched. Visual studio does this, yet not really useful (the version numbers are very long!), this seems to show that there could be a logic behind the convention used. I just cant parse it.

To take an example (leaving aside the case of big serial numbers), it's very common to use a format like this one: prog_nameN.M. N is a number, and M another, with sometimes letter at the end:

Code: Select all

'example
myprog1.02b

This all said; my question is simply about the meaning of M and N and how to decide how to get them incremented.

I think for example that a rational rule could be like: "more than 100% of my previous code has changed THEN M += 1". While in another hand, the decimal part N should be ruled more finely.

If someone knows about this, and has some ideas or experience of a good system to maintain version numbering, would be glad to hear about it (any kind of personal suggestion is welcome anyway).

By advance, thanks.

[RockTheSchock]

I'm trying to rationalize my code files names (on disk) appending a version number to them.

I wouldn't append numbers to source code files! Use a versioning system like git https://en.wikipedia.org/wiki/Git_%28software%29

With git you can document all changes transparently. You can set branches. You can see differences between different versions of a file...

I prefer to use release version numbers like:

Version < 0.2.0 = ALPHA
Version < 1.0.0 = BETA
Version >= 1.0.0 STABLE

1.1.9 -> 1.1.10 Bugfix
1.2.x -> 1.3 Added one/severeal signifikant features / signifikant internal modifications
1.x.x -> 2.0 Fundamental change of features / maybe deprecate or modify extisting public API / parameters


I hate to see FIrefox / Chrome / IE version numbers like 50.12.1

[Tourist Trap]

I wouldn't append numbers to source code files! Use a versioning system like git https://en.wikipedia.org/wiki/Git_%28software%29

With git you can document all changes transparently. You can set branches. You can see differences between different versions of a file...

Thanks, sounds very good. I have only a fear, my system has reached its limit in term of resident programs. I'v read carrefully the wikipedia article about GIT but nothing is said about the room it occupies on a system. Have you some info about this? Is it a resident program, does it require extra ressource to be taken into account on weaker systems? Or is it a lightweighted portable application like FB itself or stuff related to fb in general like FBIDE?...

Version < 0.2.0 = ALPHA
Version < 1.0.0 = BETA
Version >= 1.0.0 STABLE

By the way, I wonder about the exact definitions and purpose of those terms. Like ALPHA, BETA, RC, and so on. I've also sighted GOLD, and Nighty build. Of course beta, and nighty build are usual or self defined, but the others are more specific and not easy to define for a commoner like me.

[MrSwiss]

Usual Definitions:

• ALPHA: testing is still done by the Developer(s) only
  BETA: first User testing, usually by a few select Users (also called Pilot sometimes)
  RC: Release Candidate, almost ready for general Distribution, coding finished except
  ironing out some Glitches, or newly discovered Bugs. (RC1, RC2 etc. --> Release)

These Terms are mostly referring to commercial SW Development, e.g. on FBC, being
Open Source they become sometimes blurred like ALPHA/BETA at the same time ...

[RockTheSchock]

Thanks, sounds very good. I have only a fear, my system has reached its limit in term of resident programs. I'v read carrefully the wikipedia article about GIT but nothing is said about the room it occupies on a system. Have you some info about this? Is it a resident program, does it require extra ressource to be taken into account on weaker systems? Or is it a lightweighted portable application like FB itself or stuff related to fb in general like FBIDE?...

It depends what git suite you want to use. By using only command line tools it's very lightweight, but not so user friendly,especially for diffs. If you use eg. TortoiseGIT a windows shell extension, you can tweak the ram usage by changing option for icon overlay.
https://tortoisegit.org/docs/tortoisegi ... gs-overlay

There are 3 common systems: git, subversion, mercurial. Each has pros and cons:
http://biz30.timedoctor.com/git-mecuria ... -software/

For each there exists a Windows shell extension: tortoisegit,tortoisesvn, tortoisehg

For some editors like geany there are also plugins, so you can commit/update changes to/from repository with the editor.

[caseih]

Thanks, sounds very good. I have only a fear, my system has reached its limit in term of resident programs. I'v read carrefully the wikipedia article about GIT but nothing is said about the room it occupies on a system. Have you some info about this? Is it a resident program, does it require extra ressource to be taken into account on weaker systems? Or is it a lightweighted portable application like FB itself or stuff related to fb in general like FBIDE?...

I haven't heard terms like this in some years! Few younger programmers would even know what a "resident program" was. And of course the terms no longer apply, really, to how modern OS's and programs function. An idle system with plenty of free resources will have possibly hundreds of processes at play (mostly sleeping). We really were hobbled for some time by the architecture that the 8086 chip provided us (and MS DOS didn't help) by making memory below 640 kb special, and mapping things like video memory into high memory, making it very difficult to utilize memory in those special regions.

The short answer is, no, don't worry about it. As long as you have free hard drive space, there's no need to worry about git taking extra resources. Git has a learning curve, but you don't need to use all of git's features. Personally, I just use and need just a few git commands on a regular basis. There are some books on git, but also a few online tutorials. Also you do not need an account on any git hosting systems, though it might be convenient. My git repositories are all local, and I use them simply to track my changes and make it easy to roll back things. I have yet to really use tagging and branching, which are powerful features when you are actually wanting to release a version of your code to the public. Some editors like geany have built-in support for working with git.

[sancho2]

...
The short answer is, no, don't worry about it. As long as you have free hard drive space, there's no need to worry about git taking extra resources...

I could be wrong, but I think 'installed programs' is what Tourist meant by 'resident programs'.

[marcov]

My git repositories are all local, and I use them simply to track my changes and make it easy to roll back things. I have yet to really use tagging and branching, which are powerful features when you are actually wanting to release a version of your code to the public. Some editors like geany have built-in support for working with git.

I've an SVN server on a raspberry pi. It's installation and configuration is almost a no-op for a single user, and because it works over SSH too, I can access it from the outside too. If you only store source a whole repository is a couple of MBs.

Since memory cards are not 100% reliable in the long run when seriously used, I make a nightly backup onto a USB stick. I then rsync that usb stick to my workstation on every boot.

(I keep a directory of larger resources like splashscreen images on the pi too. Write access via a share (or scp), read access is via rsync-over-ssh again. Not versioned so newer versions simply get a different name.)

[marcov]

I'm trying to rationalize my code files names (on disk) appending a version number to them.

I wouldn't append numbers to source code files! Use a versioning system like git https://en.wikipedia.org/wiki/Git_%28software%29

With git you can document all changes transparently. You can set branches. You can see differences between different versions of a file...

I prefer to use release version numbers like:

Version < 0.2.0 = ALPHA
Version < 1.0.0 = BETA
Version >= 1.0.0 STABLE

1.1.9 -> 1.1.10 Bugfix
1.2.x -> 1.3 Added one/severeal signifikant features / signifikant internal modifications
1.x.x -> 2.0 Fundamental change of features / maybe deprecate or modify extisting public API / parameters

It reminds of standard Linux kernel derived versioning practices (before 3.0) that a lot of projects use, but the 0.2.0 and <1.0.0 are a bit random.

In addition,

first number: only changes on fundamental or (heavily) backwards compatibility breaking changes
Middle number odd: unstable branch
Middle number even: stable release
last number odd : rolling version
last number even : tag of a specific release (might be from unstable branch too, in that case a alpha/beta)

Sometimes additional suffixes are used (like -RC to denote release candidates, or -DP for developer's preview (FreeBSD did this to test release packaging for a major new branch as a kind of Alpha. Alpha probably sounded to negative)

I hate to see FIrefox / Chrome / IE version numbers like 50.12.1

I don't like the marketing driven versionnumbers too. Some use year.quarter, which is fine for very big projects, but for smaller projects that is too inflexible

[Tourist Trap]

Thanks a lot all for those very interesting answers.

If you use eg. TortoiseGIT a windows shell extension, you can tweak the ram usage by changing option for icon overlay.
https://tortoisegit.org/docs/tortoisegi ... gs-overlay

I think I'll give this a try since the documentation is quite clear. Can't say when I will be able to launch an install for I've to close and save many running apps each with many works started inside that I must examine before saving or discarding. That's one of the reason I want a good classification system for source code.

Oops, I've some doubt about what GIT version I could use with TortoiseGIT.... I've downloaded TortoiseGIT 1.8.16 but seems to be only a wrapper and still require a GIT program. So got PortableGIT 2.6.4. But after reading the tortoise doc, seems that "Git for windows" is recommanded. As I don't find portable version of this, I would really prefer to stick with PortableGIT. However not sure too much about the compatibility in this case, nothing clear for me told about this. PortableGIT is also from the http://git-scm.com which seems to be the official website, but not a word about it on tortoise. Sorry for my ignorance, but seems to be hard to figure out why so many versions of GIT for windows?

I could be wrong, but I think 'installed programs' is what Tourist meant by 'resident programs'.

I'm speaking about those processes running on background that are eating my computer ressources and that I pain to discard, or because they are useful like antivirus (kaspersky is nice but has became heavy with the years), or the stuff that installs itself and is so hard to remove like oracle services, java now that it is ruled by oracle, apple stuff, adobe updaters, not to mention google which I've banned from my system so much invading it was (days of registery cleaning)!

Given that I'm running an only 1Go XP system, I think you can imagine how close to the deadlock my system stands most of time. The second problem I have is a low main partition space (C:/ is only 80 Go, and is just saturated). As a result I've often to consider removing nice stuff like CygWin that was too hard to keep running on this partition.

Whatever, and if you wonder, I still want to keep this system configuration for it is useful to test programs in a limited ressource context. First I can actually feel when a software is doing crap, because it generally consumes ressources to some excessive extend (fb is not in this category!). Moreover a program (possibly something I'm coding) that runs smooth in my system should only feel better on an other one. -- I'm thinking however upgrading up to 2Go ram.