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
Signature · 6 lines
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 at 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.
Quoted 23 lines · Wolfgang Denk
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
Quoted 7 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
---------- Forwarded message ----------
From: Andrew Dyer <[email protected]>
Date: Fri, Aug 1, 2008 at 10:39 AM
Subject: Re: [U-Boot-Users] RFC: U-Boot version numbering
To: Kumar Gala <[email protected]>
Quoted 4 lines · Kumar Gala
If we go to date based versions. I'd prefer we keep year as 4 digits:
v1.2008.10
v1.2009.01
I agree, although doing that makes the third field look like a month to the uninitiated. Perhaps use a letter like 'r' for revision instead of a period for the second separator like so:
v1.2008r06
--
Hardware, n.:
The parts of a computer system that can be kicked.
Signature · 2 lines
Hardware, n.: The parts of a computer system that can be kicked.
Quoted 11 lines · In message <[email protected]> you…
Quoted 4 lines · Kumar Gala
If we go to date based versions. I'd prefer we keep year as 4 digits:
v1.2008.10
v1.2009.01I agree, although doing that makes the third field look like a month to the uninitiated. Perhaps use a letter like 'r' for revision instead of a period for the second separator like so:
But it *is* a month...
Quoted 1 line
v1.2008r06
v1.2008.06 would mean the June release in year 2008.
Best regards,
Wolfgang Denk
Signature · 5 lines
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 at denx.de "Morality is one thing. Ratings are everything." - A Network 23 executive on "Max Headroom"
Quoted 37 lines · Kumar Gala
Quoted 23 lines · Wolfgang Denk
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
Quoted 8 lines
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:
Quoted 8 lines
v1.2008.10
v1.2009.01It 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 :
Quoted 40 lines
Quoted 39 lines · Kumar Gala
Quoted 23 lines · Wolfgang Denk
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
Quoted 8 lines
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
Quoted 6 lines
Quoted 5 lines
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,
Signature · 1 line
Albert.
Quoted 48 lines · Albert ARIBAUD
Ben Warren a ?crit :
Quoted 40 lines
Quoted 39 lines · Kumar Gala
Quoted 23 lines · Wolfgang Denk
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
Quoted 8 lines
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.01Quoted 6 lines
Quoted 5 lines
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.
Quoted 7 lines
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 at lists.sourceforge.net wrote on :
Quoted 42 lines
Quoted 41 lines · Kumar Gala
Quoted 23 lines · Wolfgang Denk
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
Quoted 8 lines
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
Quoted 6 lines
Quoted 5 lines
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.
Quoted 31 lines
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
Quoted 28 lines
Comments?
Best regards,
Wolfgang Denk
Signature · 20 lines
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 at 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 at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
Wolfgang Denk a ?crit :
Quoted 27 lines
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.
Quoted 5 lines
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,
Signature · 1 line
Albert.
Quoted 5 lines · 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.
Quoted 3 lines
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?
Quoted 3 lines
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
Signature · 5 lines
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 at denx.de 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]>
Quoted 4 lines · Wolfgang Denk
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
Quoted 7 lines · Ken.Fuchs at bench.com
Quoted 4 lines · Wolfgang Denk
Well, the "version 2" prefix is kind of already taken by Sascha Hauers alternative implementation.
Should we go for 2.x.x anyway?
Quoted 8 lines
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
Quoted 17 lines
Quoted 6 lines
Quoted 4 lines · Wolfgang Denk
Well, the "version 2" prefix is kind of already taken by Sascha Hauers alternative implementation.
Should we go for 2.x.x anyway?
Quoted 8 lines · Ken Fuchs
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.
Quoted 2 lines · Scott Wood
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.
Quoted 1 line
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.
Quoted 1 line
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
Quoted 45 lines · Albert ARIBAUD
Wolfgang Denk a ?crit :
Quoted 27 lines
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.
Quoted 6 lines
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. :)
Quoted 9 lines
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 :
Quoted 1 line
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. :)
Quoted 3 lines
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,
Signature · 1 line
Albert.
Quoted 52 lines · Feng Kan
Quoted 51 lines · Albert ARIBAUD
Wolfgang Denk a ?crit :
Quoted 27 lines
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.
Quoted 6 lines
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?
Quoted 7 lines
Quoted 2 lines
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
Quoted 10 lines · u-boot-users-bounces at lists.sourceforge.net
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.
Quoted 4 lines
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
Quoted 6 lines · 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
Signature · 5 lines
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 at denx.de 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
[U-Boot-Users] 1.3.4-rc2 autoboot timeout - MPC8548
In reply to Wolfgang DenkAutoboot 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
[U-Boot-Users] 1.3.4-rc2 autoboot timeout - MPC8548
Quoted 9 lines · In message <[email protected]> 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
Signature · 4 lines
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 at denx.de Lots of folks confuse bad management with destiny. -- Frank Hubbard
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
Quoted 55 lines · --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: wd at 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 at 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
Quoted 37 lines · Wolfgang Denk
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