Hi,
in general I totally ack to a new version numbering scheme.
When we are releasing U-Boot for some of our hardware this is typically done asynchronous to the U-Boot release cycle. We (often) cannot wait until a new U-Boot is released. So we take the current U-Boot version + build date/time as effective version.
We also used CONFIG_IDENT_STRING to identify a special version some time ago. But I do not like it much.
Do you see a better way to identify a special U-Boot version? EXTRAVERSION could be fine, but it is already used to release candidates etc.
What is common practice in other companies?
Matthias
On Friday 01 August 2008 17:32, Wolfgang Denk wrote:
Hello,
I would like to get your general opinion about changing the U-Boot version numbering scheme.
To be honest, I never really understood myself how this is supposed to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. e. which changes / additions are important enough to increment the PATCHLEVEL or even VERSION number.
I therefor suggest to drop this style of version numbering and change to a timestamp based version number system which has been quite successfully used by other projects (like Ubuntu) or is under discussion (for Linux).
My suggestion for the new version numbers is as follows:
VERSION = 1 (at least for the time being)
PATCHLEVEL = current year - 2000
SUBLEVEL = current month
Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for the next 91+ years to come) so listings for example on an FTP server shall be in a sane sorting order.
If we accept this system, the next release which probably comes out in October 2008 would be v1.08.10, and assuming the one after that comes out in January 2009 would be named v1.09.01
Comments?
Best regards,
Wolfgang Denk