Feng Kan schrieb: > Albert ARIBAUD wrote: >> Wolfgang Denk a écrit : >> >>> 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? >>> >> A minor :) issue I can see is that there might be *some* confusion >> because of an apparent, numerical rollback from 1.3.4 back to 1.08.xx. >> You're bound to encounter some folks who will ask, again and again, why >> you're working on 1.02.yy when 1.3.4 is out there. >> >> Now an obvious solution would be to use 2 as the major number. If you're >> serious about not knowing when a major number bump-up is required, then >> you should be fairly ok with starting at 2.08.01 rather than 1.08.01. :) >> >> Joke aside: you'll get questions *anyway*, and the scheme is as fine to >> me as it it. >> >> Another, maybe trickier, issue is: you won't be able to cleanly number >> interim releases if you encounter a really serious bug right after >> you've produced this month's release, will you? >> >> Amicalement, >> > Perhaps the Version itself can be removed, there doesn't seems to be a > point about it. > You can just do v2008.1. You can add a third field for the day for those > really serious > bugs:)
Partially ack. In principle, the version prefix is unnecessary, because year and month are clear. But it helps when sorting the version due to the existing "v1". For subversions I suggest a sequential number as suffix or an arbitrary string, e.g.: v2.2008.10-001 v2.2008.10-rc2 v2.2008.10-projectX v2.2008.10-experimental_091 Any opinions about upper case / lower case notation? Kind regards, Jens ------------------------------------------------------------------------- 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