[U-Boot-Users] RFC: U-Boot version numbering

[Matthias Fuchs <matthias.fuchs@esd-electronics.com>]

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
>