Subject: UADE2 version numbers

From: shd
Date: Mon Dec 12 03:41:10 2005

To: UADE-Developer-discussion
I'm open to questions about what version number and what version number style to use for first stable uade2 release? Some possibilities on release file names:

 - uade-2.00.tar.bz2, continuing with 2.01, ...
 - uade-2.0.tar.bz2, continuing with 2.1, ..., 2.10

The philosophy has been that each release presents a small incremental change (except this one which is a step from uade1 to uade2). I would like to avoid version numbering that separates production and development branches (excuse the loaded words) to test changes as rapidly as possible. IMO, it has worked pretty well so far, or otherwise the users haven't reported enough bugs to me so I have an illusion.

---

From: amadeus
Date: Fri Dec 16 08:25:29 2005

To: UADE-Developer-discussion
I have just checked Wikipedia to get some ideas, and version numbering is a science of its own :D
[url]http://en.wikipedia.org/wiki/Version[/url]

Personally do I prefure the Apache  approach
[quote:b210d82517]     Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.

    It is important to note that a library that has not reached 1.0.0 is not subject to the guidelines described in this document. Before a 1.0 release (version 0.x.y), the API can and will be changing freely, without regard to the restrictions detailed below.
[/quote:b210d82517]
[url]http://apr.apache.org/versioning.html[/url]

One think that is for sure though is, that after 1.4 comes 5.0  :D 

Microsoft however always exaturates, so they jump from 3 -&gt; 95 -&gt; 98 -&gt; 2000. :D

---

From: shd
Date: Fri Dec 16 13:41:43 2005

To: UADE-Developer-discussion
Perhaps using three numbers would be good, but I never guarantee binary or source compatibility between any two versions. If there's an opportunity to make code better, and I have motivation to change it, I'll do it. Here "better" means combination of easier to read, faster, more suitable functionality and prettier.