Re: Current stable tag slip status
Ed wrote:
> On Monday 21 March 2005 02:29, Matthew Dillon wrote:
>
>> After the stable tag is slipped we will begin release engineering for
>> a release prior to USENIX (which I will be at, BTW). I am going to
>> call this release 1.5 oweing to the fact that the big ticket journaling
>> item isn't done. The release date will be in early April.
>>
>> Then, tentatively, since so much progress is being made, the 2.0
>>release will likely occur in September.
>
>
>
> I'd suggest to use lower release numbers.
> I think it's better to call 1.1 the April release, and then 1.2 and so.
>
> The fact is that if you jump from major numbers (1.x to 2.x) every year, the
> first DF release with all the cool features will have a big number like 7 or
> 8. And I don't think it's a good idea. Think at Mandrake 10, RedHat 10,
> Solaris 10 and so on.
>
> Also, if you follow my advice you could be able to make a big step for a
> particular milestone, for example jumping from 2.3 to 3.0. That would not be
> possible if you already jump by 0.5 every 6 months.
>
I'm sure to branded a heretic here, but the 'numbers game'
is one of the less-attractive features of software.
How about a system such as:
STABLE releases = DFSMMMYY
- *never* a day, no suffix for major 'milestone' releases
- *2 digit* suffix for up to 100 per-month incremental changes.
i.e. DFSAPR05, DFSAPR05.08
CURRENT releases = DFCMMMDDYY
- *always* a day
- *1 digit* suffix for up to ten per day incremental changes/patches
i.e. DFCAPR0205, DFCAPR0205.01, DFCAPR0305.1, DFCAPR0305.2
EXPERIMENTAL or testing versions = DFXMMMDDYY.nn
- *always* a day
- 3-digit suffix handles as many as 100 on any given day...
Rationale for including 'DFS', 'DFC', or 'DFX' is immediate
and easy ID from uname -a or whatever.
I've seen too many threads (elsewhere) and even a
few here where information sought and
advice given were not in sync 'coz the parties were
not talking about the same code base.
YMMV.
Bill
討論串 (同標題文章)
完整討論串 (本文為第 2 之 15 篇)：