[U-Boot] U-Boot Versioning
Hi,
after some discussions in the past I propose to use the following numbering scheme for future releases of U-Boot (starting with the upcoming one):
* Regular releases (about once every two months or so) shall be named "YYYY.MM" with YYYY = year as 4 digits, MM = month (01..12)
In other words: VERSION = year as 4 digits PATCHLEVEL = month as 2 digits
That means the upcoming release, which is scheduled for October 2008, would be named "2008.10".
* Intermediate releases, that might become necessary because of serious bugs or other major problems, shall be indicated by incrementing the "SUBLEVEL" field.
SUBLEVEL = 0 corresponds to the original release version and is usually omitted, i. e. while "2008.10" and "2008.10.0" are considered to be the same, the normal notation shall be "2008.10" only. [See "stable trees below"]
That means, if we should have two intermediate releases following the normal, scheduled release "2008.10", these would be numbered as "2008.10.1" and "2008.10.2", respectively.
* There may be a need to fix problems with older releases, i. e. to maintain "stable trees" similar to what Linux is doing. We will use the "EXTRAVERSION" field to identify versions in such stable trees.
So "2008.10.0.y" stands for versions in the stable tree branching off the "2008.10" release, and "2008.10.2.3" would be the 3rd version the stable tree branching off the 2nd intermediate releases following release "2008.10".
I think we will most probably not need all this complexity (we didn't need it in the last 8 years of U-Boot development), but I think it's a good idea to be prepared in case anybody asks for it.
To summarise: I intend to name the upcoming release "2008.10".
Are there any important arguments against this versioning scheme ?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Hi,
after some discussions in the past I propose to use the following numbering scheme for future releases of U-Boot (starting with the upcoming one):
Regular releases (about once every two months or so) shall be named "YYYY.MM" with YYYY = year as 4 digits, MM = month (01..12)
In other words: VERSION = year as 4 digits PATCHLEVEL = month as 2 digits
That means the upcoming release, which is scheduled for October 2008, would be named "2008.10".
Sounds good to me, although I have a hard time imagining needing four levels. "Be prepared" I guess. ;-)
[snip]
Are there any important arguments against this versioning scheme ?
Not from me.
Of course, we need silly alphabetical animal names for "code names." No, wait, that's been done before. I know! We can use u-boat names for the code names. We can start with the code name "Unterseeboot 1." http://en.wikipedia.org/wiki/List_of_U-boats
;-P
Best regards, Wolfgang Denk
Best regards, gvb
Dear Jerry Van Baren,
In message 48B87C4D.2060004@gmail.com you wrote:
Of course, we need silly alphabetical animal names for "code names."
Do we?
No, wait, that's been done before. I know! We can use u-boat names for the code names. We can start with the code name "Unterseeboot 1." http://en.wikipedia.org/wiki/List_of_U-boats
;-P
Or use colors.
The next release will then be the Yellow Submarine :)
Best regards,
Wolfgang Denk
Il sabato 30 agosto 2008 01:12:31 Wolfgang Denk ha scritto:
Dear Jerry Van Baren,
In message 48B87C4D.2060004@gmail.com you wrote:
Of course, we need silly alphabetical animal names for "code names."
Do we?
No, wait, that's been done before. I know! We can use u-boat names for the code names. We can start with the code name "Unterseeboot 1." http://en.wikipedia.org/wiki/List_of_U-boats
;-P
Or use colors.
The next release will then be the Yellow Submarine :)
Anyway give a name to the realeases is good idea.
my2eurocents
luigi
Best regards,
Wolfgang Denk
On Sat, Aug 30, 2008 at 01:12:31AM +0200, Wolfgang Denk wrote:
Or use colors.
The next release will then be the Yellow Submarine :)
We've also considered to name toolchain releases after food. So for example if gcc-4.3.2 would be spagetti, binutils-2.18 would be tomatos, glibc-2.8 would be mincemeat; so a release from these components could be called the "spagetty bolognese" release, which would definitely be better than gcc-4.3.2-glibc-2.8-kernel-2.6.26-arm-v4t-linux-gnueabi.
The problem comes up if you upgrade binutils to the 2.19 "pickled herring" revision. The resulting toolchain could have some compatiblity issues with our users then :)
rsc
Il lunedì 01 settembre 2008 17:54:08 Robert Schwebel ha scritto:
On Sat, Aug 30, 2008 at 01:12:31AM +0200, Wolfgang Denk wrote:
Or use colors.
The next release will then be the Yellow Submarine :)
We've also considered to name toolchain releases after food. So for example if gcc-4.3.2 would be spagetti, binutils-2.18 would be tomatos, glibc-2.8 would be mincemeat; so a release from these components could be called the "spagetty bolognese" release, which would definitely be better than gcc-4.3.2-glibc-2.8-kernel-2.6.26-arm-v4t-linux-gnueabi.
good idea... but I would like to clarify that we (italians) don't eat Spaghetti with Bolognese but we prefer to use Tagliatelle or Tortellini or Ravioli pasta, and the Sugo Bolognese's ingredients are: - Onion - Olive Oil (Extra-virgin!) - Celery - Carrot - Wine - (little bit) milk (if you want) - minced meet (beef) - (litte bit) lard or bacon (if you want) - tomato - a lot of time
Using the Sugo alla Bolognese we can give a name for each file of the toolchain...
ciao
luigi
The problem comes up if you upgrade binutils to the 2.19 "pickled herring" revision. The resulting toolchain could have some compatiblity issues with our users then :)
rsc
On Tue, Sep 02, 2008 at 09:37:04AM +0200, Luigi 'Comio' Mantellini wrote:
good idea... but I would like to clarify that we (italians) don't eat Spaghetti with Bolognese but we prefer to use Tagliatelle or Tortellini or Ravioli pasta, and the Sugo Bolognese's ingredients are:
- Onion
- Olive Oil (Extra-virgin!)
- Celery
- Carrot
- Wine
- (little bit) milk (if you want)
- minced meet (beef)
- (litte bit) lard or bacon (if you want)
- tomato
Well, that surely qualifies for the releases for the next couple of years.
- a lot of time
Uuuh, that's not so easy. Code incredients tend to rot quickly when not being served freshly from a rcs repository.
Using the Sugo alla Bolognese we can give a name for each file of the toolchain...
So it might be an innovative model, thanks, we'll reconsider! 8-)
rsc
Hello,
On Fri, Aug 29, 2008 at 11:19 PM, Wolfgang Denk wd@denx.de wrote:
after some discussions in the past I propose to use the following numbering scheme for future releases of U-Boot (starting with the ... That means the upcoming release, which is scheduled for October 2008, would be named "2008.10".
- Intermediate releases, that might become necessary because of
serious bugs or other major problems, shall be indicated by incrementing the "SUBLEVEL" field. ... From experience with other open-source projects:
I would remove this level, and use the third level for stable branch bugfixes releases instead.
It is very unlikely to release feature-upgrade releases within one month/
Leon.
Dear Leon,
In message c384c5ea0808291553l21e00c6eg37f229cea0112be1@mail.gmail.com you wrote:
- Intermediate releases, that might become necessary because of
serious bugs or other major problems, shall be indicated by incrementing the "SUBLEVEL" field. ...
From experience with other open-source projects:
I would remove this level, and use the third level for stable branch bugfixes releases instead.
This was my original intention, too. But there were a couple of people asking for ways to do hot fix releases if things were terribly broken.
It is very unlikely to release feature-upgrade releases within one month/
Not feature upgrades; urgent bug fixes.
Frankly, I don't think that we need more than the regular, plain releases. But some of us are customer-driven, so both stable trees and bug fix releases may become necessary, and the suggested scheme allows for both.
Best regards,
Wolfgang Denk
participants (5)
-
Jerry Van Baren -
Leon Woestenberg -
Luigi 'Comio' Mantellini -
Robert Schwebel -
Wolfgang Denk