[xibo]

Hello again

This time i will explain what version numbers are good for

Normal Userland Software

name a.b.c

where 'name' is the name of the software, a is it's major release number, b is the minor release number, and c is the bugfix release. On 3rd-people provided operating systems ( namely the many linux distributions that are out there ) a fourth number may appear, called the rebuild. Keep in mind that a,b,c and eventual d are numbers and not digits, cases where a number larger then 9 was used appear often. unless otherwise stated, the numbers can be considered decimal.

major release: a major release will introduce new functionallity, eventually replacing or removing old functionality that is no longer wanted any more. if a major release number gets bumped it usually means that vital elements of the software have been changed, and the new release is most times not API-compatible ( see below ) to its precedor any more
minor release: a minor release can introduce new functionallity and remove functionallity that was marked deprecated in previous releases of the same major version. by introducing new functionallity API changes occur but that doesn t need to mean that the api becomes incompatible. minor releases usually are binary incompatible ( see below ) to their precedors
bugfix release: sometimes also called patch release. bugfix releases do not add or remove functionality, but may mark unwanted things as deprecated and to be removed in future versions. bugfix releases usually are binary compatible
rebuild release: only appears in 3rd distribution. linux/hurd/bsd/... and all it's software are developed by different groups but collected and put together by distributors. these distributors can make errors when it comes to mixability of certain software, which causes unwanted side effects, or new versions of libraries get released which break binary compatibilty of programs using them. in order to fix this, the distributors ( bad mixability ) either dis or enable features or ( binary incompatibility ) just rebuild the affected programs.


snapshot versions

name a [.b[.c]] yyyy[-]mm[-]dd

name is again the software name, a it's major version ( see userland software ), b and c are optional minor and bugfix versions ( see userland software again ), the yyyy-mm-dd or more commonly yyyymmdd is the date the snapshot was taken, yyyy is the year, mm the month and dd the day. it is given in "major order" because the most important part of the date is the year, then comes the month then the day, so a lexical sorting algorithm will sort the snapshots by the order they were made. Since snapshots are rarely taken more then once a day, this data is sufficent for identification. Some projects ( i only know of mozilla ) take snapshots multiple times a day; then the hour (in 24h format), minute and second is appended, so mozilla 1.6 20011201000001 is a mozilla 1.6 snapshot from first december 2001, made on 00:00:01 gmt.


revision
nowadays developer teams usually use some kind of code versioning system (cvs) - not because of the versioning but rather because a "side feature" of applying patches to files in the developent tree rather then overwriting them, which allows multiple people to work at the same file in the same time.
a new tree allways has revision 0. each time a developer commits a patch(set) to the tree, this number is incremented by one.
Therefore the numbers haven't any higher meaning, other then a lot of numbers in few time either meaning the software is being currently quickly developed, or the devs just sending individual file patches instead of patchsets for multiple files.

EDIT>>
prerelease versions

pre-alpha release: usually uses snapshot versioning. the version of the program is in a stage where the developers haven't yet designed whether this or that feature should really make it into the next version or not. all kinds of changes can still occur to pre-alpha software until release. only major and minor releases are considered to have this phase, as bugfixes aren t supposed to introduce new functionality
alpha release: Usually called >=x.80 where x is the previous release. An alpha release is a version of a tree in a stage where api-changes may occur, but the final version has already be designed, so no yuber-changes any more. that means, functionality changes between alpha A and alpha B can and usually also do occur. Again, alpha phase is only availible to major and minor releases.
beta release: Usually called >=x.90, where x is the previous release. A beta release is a version where api-changes may not occur any more. only bugfixes and string(that is, text that the end user will see on the screen, i.e. translation foo)-changes are allowed.
release candidate: Usually called >=x.99, where x is the previous release; also called rc. A release candidate is supposed to be renamed to the next release version if everything goes good. Only bugfixes marked with high priority are applied to a release candidate. If *any* kind of patches are supposed to affect a rc, a new rc will be released before the final release.
<<EDIT


some details:
API compatibility: A library is conisidered API(advanced programing interface) compatible to another version of itself if all global scope data structures are present in both, and all function from both, taking the same parameters are supposed to cause the same behaviour. If version A is API compatible to version B, A may contain functions and global-scope variables that are not present in B, but must allways contain ALL of B's global variables and functions.
API incompatibility in reality always implies Binary Incompatibility.

Binary compatibility: In real world, it implies API-compatibility.
Different ways of library / function loading were developed, they were differenty well and only a few are actually in use. Unlike API-compabitily binary compatibility is not decided at programming-time, but rather on compile/link time. A library compiled with option A might be incompatible with a library compiled with option B ( especially changing the way how parameters are given to functions breaks compatibility, e.g. the caller might give parameters residing in stack-memory while the called function expects them to be in processor registers ), or a library compiled with compiler A can be incompatible to another one compiled with compiler B ( this is especially destructive to C++ written applications )

Bad Programming Practices: If there are 3 variables in a library version a.b.c.d, and compiler a orders them to be all 3 "in a row", stupid people could take the address of the first, and increase it by the size of the first variable to get to variable 2. however, variable allignment is something that is *highly* platform specific, and if version a.b.c.d gets relinked with another version of compiler a, another compiler, other compile options, a different runtime library or even operating system, there is nothing assuring you the 3 variables will be "in a row" again.
Another very common bad practice is allocating less memory then is used. Due to the way operating systems manage memory there is always a minimal amount of memory that is at least allocated. that means, if you allocate 1 octet of memory you can expect to get at least Y octets of memory because that is the smallest chunk the OS's memory manager can index ( Y is dependent on the operating system ). Therefore allocating less memory then you use is not neccessarily going to break something - unless you overdo it ( e.g. allocating 3 octets and assuming 20 might work but allocating 1ko and expecting 1Mo will certainly have at least side effects ). Because this is something that is hard to trace in allready-written code that runs on only one platform anyway, this is usually not done unless the memory manager of the operating system changes the minimal allocatable size ( that's exactly why so many windows xp(5.1)/2k(5.0)/nt(4~5)/workgroups(3.5)/95(4.0)/98(4.1)/me(4.9)/os2(3.5)/os2warp(3.9) programs do not work any more in windows vista even though they are perfectly api-compatibly to vista )

dot zero versions: .0 versions, usually x.0.x and especially x.0.0 are considered especially unstable, and it is not recommended to non-developers or testers to do important things with dot zero versions.