[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
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
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
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 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
u-boot-users-bounces@lists.sourceforge.net 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
On Fri, 1 Aug 2008, Wolfgang Denk wrote:
That is fine but I suggest changing version to 2. If we keep it at 1 it will be confusing because we do already have a bunch of 1.xx.xx releases. Other than that I agree.
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
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
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,
In message 48932F41.6020605@free.fr 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
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
On Wed, Aug 06, 2008 at 11:47:22AM -0500, Ken.Fuchs@bench.com 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
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
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?
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,
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
u-boot-users-bounces@lists.sourceforge.net 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).
Hi, 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.
Even when using timestamp schemes, people often attach numerical version numbers when refering to some releases. That would probably the case for the U-Boot V2 that is currently under developement. That just adds up to the confusion.
Then in some time, maybe someone will propose to switch to a name based version scheme, and so on, and so on... :)
Hugo V.
Hugo Villeneuve Hardware developer | Concepteur matériel Lyrtech Phone/Tél. : (1) (418) 877-4644 #2395 Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395 Fax/Téléc. : (1) (418) 877-7710 www.lyrtech.com Infinite possibilities...TM
In message 42848A5C5A0D1E47B026E644DD49B08E028D8045@mail 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
Autoboot timeout in 1.3.4-rc2 prints incorrectly on my system.
We have a system based closely off of the mpc8548cds system. Prior builds (1.3.4-rc1) didn't have this problem. Now during boot, the autoboot announcement is incorrect. It is set for 1 second and actually works in 1 second, but the printed statement is wrong. It says, "Autoboot in 2146991868 seconds..."
Any ideas for me?
Thanks, Zach
In message 489356C6.7020709@ripcode.com you wrote:
Autoboot timeout in 1.3.4-rc2 prints incorrectly on my system.
We have a system based closely off of the mpc8548cds system. Prior builds (1.3.4-rc1) didn't have this problem. Now during boot, the autoboot announcement is incorrect. It is set for 1 second and actually works in 1 second, but the printed statement is wrong. It says, "Autoboot in 2146991868 seconds..."
Any ideas for me?
That's the price you have to pay for maintaining an out of tree version. If your code had been merged into mainline, it would have continued to work, I bet.
I guess (and I can only guess, as you did not provide any relevant information) that you might be using the CONFIG_AUTOBOOT_PROMPT feature in your config file, and that you did not fix your board config file afterpulling in the latest versions.
Please see the (changed) description of CONFIG_AUTOBOOT_PROMPT in the README, and check what commit c37207d7 is doing; then implement a similar change in your board config file.
Best regards,
Wolfgang Denk
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
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
participants (14)
-
Adrian Filipi -
Albert ARIBAUD -
Ben Warren -
Feng Kan -
Hugo Villeneuve -
Jens Gehrlein -
Ken.Fuchs＠bench.com -
ksi＠koi8.net -
Kumar Gala -
Martin Krause -
Matthias Fuchs -
Scott Wood -
Wolfgang Denk -
Zach Sadecki