From: Jens Gehrlein <sew_s@tqs.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: U-Boot version numbering
Date: Mon, 04 Aug 2008 09:33:33 +0200 [thread overview]
Message-ID: <4896B0CD.3070905@tqs.de> (raw)
In-Reply-To: <4893846E.3060606@amcc.com>
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
next prev parent reply other threads:[~2008-08-04 7:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 15:32 [U-Boot-Users] RFC: U-Boot version numbering Wolfgang Denk
2008-08-01 15:35 ` Kumar Gala
[not found] ` <c166aa9f0808010839s7cbd81b9j2680ea4a6197bcd8@mail.gmail.com>
2008-08-01 15:40 ` [U-Boot-Users] Fwd: " Andrew Dyer
2008-08-01 18:41 ` Wolfgang Denk
2008-08-01 16:15 ` [U-Boot-Users] " Ben Warren
2008-08-01 17:44 ` Albert ARIBAUD
2008-08-01 17:51 ` Ben Warren
2008-08-04 7:11 ` Martin Krause
2008-08-01 15:36 ` ksi at koi8.net
2008-08-01 15:44 ` Albert ARIBAUD
2008-08-01 18:45 ` Wolfgang Denk
2008-08-06 16:47 ` Ken.Fuchs at bench.com
2008-08-06 17:42 ` Scott Wood
2008-08-06 18:44 ` Ken.Fuchs at bench.com
2008-08-01 21:47 ` Feng Kan
2008-08-01 22:02 ` Albert ARIBAUD
2008-08-04 7:33 ` Jens Gehrlein [this message]
2008-08-01 15:51 ` Hugo Villeneuve
2008-08-01 18:50 ` Wolfgang Denk
2008-08-01 18:32 ` [U-Boot-Users] 1.3.4-rc2 autoboot timeout - MPC8548 Zach Sadecki
2008-08-01 19:01 ` Wolfgang Denk
2008-08-01 18:46 ` [U-Boot-Users] RFC: U-Boot version numbering Adrian Filipi
2008-08-04 16:05 ` Matthias Fuchs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4896B0CD.3070905@tqs.de \
--to=sew_s@tqs.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.