Re: [U-Boot-Users] RFC: U-Boot version numbering
Wolfgang Denk wrote: Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? May I suggest CC.YY.MM? VERSION = Century number PATCHLEVEL = Year number SUBLEVEL = Month number EXTRAVERSION = NULL or special purpose So this month's release number would become 20.08.08. Sincerely, Ken Fuchs - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
On Wed, Aug 06, 2008 at 11:47:22AM -0500, [EMAIL PROTECTED] wrote: Wolfgang Denk wrote: Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? May I suggest CC.YY.MM? VERSION = Century number PATCHLEVEL = Year number SUBLEVEL = Month number EXTRAVERSION = NULL or special purpose So this month's release number would become 20.08.08. Why the extra dot after the century? That looks like August 20th, 2008 in certain date formats. And no ability to release more than once a month? Of course, we *could* base the version number on RFC 2550... :-) -Scott - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Wolfgang Denk wrote: Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? On Wed, Aug 06, 2008 at 11:47:22AM -0500, Ken Fuchs wrote: May I suggest CC.YY.MM? VERSION = Century number PATCHLEVEL = Year number SUBLEVEL = Month number EXTRAVERSION = NULL or special purpose So this month's release number would become 20.08.08. Scott Wood wrote: Why the extra dot after the century? That looks like August 20th, 2008 in certain date formats. All such date formats that list smaller units (days) before larger units (months or years) such that they don't sort properly are deprecated. And no ability to release more than once a month? The EXTRAVERSION preprocessor symbol can be defined to allow a new release every picosecond, or more often, if necessary. Of course, we *could* base the version number on RFC 2550... :-) To solve the Y10K, Y100K, Y1M, ... problems, the CC in CC.YY.MM shall be defined to be as long as necessary. -- OK, reserving VERSION for Century number may not be such a good idea after all. Here's another suggestion that most may agree with: VERSION =Year number = 2008..10**30-1 PATCHLEVEL = Month number = 1..12 SUBLEVEL = Day number = 1..31 EXTRAVERSION = NULL or special purpose A release on the opening day of the Olympics would be: 2008.08.08 Sincerely, Ken Fuchs - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
[EMAIL PROTECTED] wrote on : Kumar Gala wrote: On Aug 1, 2008, at 10:32 AM, 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 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - k I vote for this one, but starting at v2. Me too! Best Regards, Martin -- TQ-Systems GmbH Muehlstrasse 2, Gut Delling, D-82229 Seefeld Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913 Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl http://www.tq-group.com - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
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 - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] RFC: U-Boot version numbering
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: [EMAIL PROTECTED] 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Kumar Gala wrote: On Aug 1, 2008, at 10:32 AM, 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 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - k I vote for this one, but starting at v2. regards, Ben - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Ben Warren a écrit : Kumar Gala wrote: On Aug 1, 2008, at 10:32 AM, 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 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - k I vote for this one, but starting at v2. Just one thing: Verson numbering can be anything you want, but I think it should be self-consistent. And on that account, I realize that the v1 part has no real meaning wrt to the rest of the version string, which date-related -- unless there is a plan to have simultaneous v1 and v2 releases, in which case it makes sense to have v1. Amicalement, -- Albert. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Albert ARIBAUD wrote: Ben Warren a écrit : Kumar Gala wrote: On Aug 1, 2008, at 10:32 AM, 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 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - k I vote for this one, but starting at v2. Just one thing: Verson numbering can be anything you want, but I think it should be self-consistent. And on that account, I realize that the v1 part has no real meaning wrt to the rest of the version string, which date-related -- unless there is a plan to have simultaneous v1 and v2 releases, in which case it makes sense to have v1. Amicalement, Yes, in this case the meaning of 'v2' is new version naming scheme, not new software version. It probably is superfluous. regards, Ben - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
In message [EMAIL PROTECTED] you wrote: 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. Good point. I have to admit that I was reading 1.08.xx same as 1.8.xx; the leading 8 is just there to make sure that 1.08.xx sorts before 1.10.xx. 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. :) Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? 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? Well, we can always use EXTRAVERSION to add some additional name, as we do all the time for our -rc? prereleases. 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: [EMAIL PROTECTED] I think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in [EMAIL PROTECTED] - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
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-.mm for the master git branch and maybe u-boot-experimental-.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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
In message [EMAIL PROTECTED] you wrote: IMHO I think it is best to stick with the same version numbering scheme that you started with, even if it is not perfect. The alternative timestamp scheme is not perfect either. You can probably find as many advantages for one as for the other, and the same goes for the disadvantages. Well, obvious advantages of the timestamp based version number include: * It better matches our current development model, which is planning for a more or less fixed relese cycle (versus foir example feature based releases). * It makes it much more easy to find out how old a version is. At the moment, if someone reports problems with version 1.1.2 you probably know that this is old stuff, but how old exactly? If the name was 1.04.04 you would have seen immediately that this was a version from April 2004, and this is *really* old. 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: [EMAIL PROTECTED] Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
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:) My two cent? - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Feng Kan a écrit : You can just do v2008.1. That would be v2008.01, then, lest we want FTP sites to put november and december releases between january and february. :) You can add a third field for the day for those really serious bugs:) What, and not be able to crank out several releases in a single day? I vote for iso-8601 compliance (up to the second and including TZ). Amicalement, -- Albert. - 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
