[U-Boot-Users] RFC: U-Boot version numbering

[U-Boot-Users] RFC: U-Boot version numbering

[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

-- 
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.

[U-Boot-Users] RFC: U-Boot version numbering

[Kumar Gala]

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

[U-Boot-Users] RFC: U-Boot version numbering

[ksi at koi8.net]

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 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.   *
******************************************************************

[U-Boot-Users] Fwd: RFC: U-Boot version numbering

[Andrew Dyer]

---------- Forwarded message ----------
From: Andrew Dyer <amdyer@gmail.com>
Date: Fri, Aug 1, 2008 at 10:39 AM
Subject: Re: [U-Boot-Users] RFC: U-Boot version numbering
To: Kumar Gala <galak@kernel.crashing.org>


On Fri, Aug 1, 2008 at 10:35 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> 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.



-- 
Hardware, n.:
 The parts of a computer system that can be kicked.

[U-Boot-Users] RFC: U-Boot version numbering

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot-Users] RFC: U-Boot version numbering

[Hugo Villeneuve]

u-boot-users-bounces at 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

[U-Boot-Users] RFC: U-Boot version numbering

[Ben Warren]

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

[U-Boot-Users] RFC: U-Boot version numbering

[Albert ARIBAUD]

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.

[U-Boot-Users] RFC: U-Boot version numbering

[Ben Warren]

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] 1.3.4-rc2 autoboot timeout - MPC8548

[Zach Sadecki]

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

[U-Boot-Users] Fwd: RFC: U-Boot version numbering

[Wolfgang Denk]

In message <c166aa9f0808010840r3f10bd4fr30454893b66b28ec@mail.gmail.com> you wrote:
>
> On Fri, Aug 1, 2008 at 10:35 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> > 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:

But it *is* a month...

> v1.2008r06

v1.2008.06 would mean the June release in year 2008.

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
"Morality is one thing.  Ratings are everything."
- A Network 23 executive on "Max Headroom"

[U-Boot-Users] RFC: U-Boot version numbering

[Wolfgang Denk]

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

-- 
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 <10911@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] RFC: U-Boot version numbering

[Adrian Filipi]

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 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
>

[U-Boot-Users] RFC: U-Boot version numbering

[Wolfgang Denk]

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

-- 
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

[Wolfgang Denk]

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

-- 
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

[U-Boot-Users] RFC: U-Boot version numbering

[Feng Kan]

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?

[U-Boot-Users] RFC: U-Boot version numbering

[Albert ARIBAUD]

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.

[U-Boot-Users] RFC: U-Boot version numbering

[Martin Krause]

u-boot-users-bounces at 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

[U-Boot-Users] RFC: U-Boot version numbering

[Jens Gehrlein]

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] RFC: U-Boot version numbering

[Matthias Fuchs]

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
> 

[U-Boot-Users] RFC: U-Boot version numbering

[Ken.Fuchs at bench.com]

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

[U-Boot-Users] RFC: U-Boot version numbering

[Scott Wood]

On Wed, Aug 06, 2008 at 11:47:22AM -0500, Ken.Fuchs at 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

[U-Boot-Users] RFC: U-Boot version numbering

[Ken.Fuchs at bench.com]

> > 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