Like a lot of others, I think v1.08.xx will be confusing alongside the existing 1.x.y releases.
As to the v1/v2 issues, the problem is that it's just a number and a greater number implies progress and a unidirectional relationship. Given that v2 already exists concurrent with v1, it's misleading. People won't know that one might not be for production.
Instead of v1/v2, I'd prefer that the first field be related to the version control branch name. i.e. u-boot-stable-yyyy.mm for the master git branch and maybe u-boot-experimental-yyyy.mm, should there ever be concurrent releases.
Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
--On Friday, August 01, 2008 11:32:52 AM -0400 Wolfgang Denk wd@denx.de 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
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users