[lkml]   [2001]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Release Policy [was: Linux 2.4.16 ]
On Mon, 26 Nov 2001, David Relson wrote:

> At 12:22 PM 11/26/01, Chris Meadors wrote:
> >Aren't all the -pre's pre-finals? And what if there is a big bug found in
> >the -final, it will obviously be followed up with a -final-final?

All the -pre's are before the final, but not release candidates. I think
the rc until recently has been the one where someone said "we've put a
hell of a lot of new stuff in this..." and concentrated on reported bugs,
if any.

> >I like the ISC's release methods. The do -rc's (-pre's would be fine for
> >the kernel as it is already established), each -rc fixes problems found
> >with the previous. When an -rc has been out long enough with no more bug
> >reports they release that code, WITHOUT changes.

> I think of -pre releases as beta code - testable and likely broken. An -rc
> release would be "possibly broken". If problems are encountered, fix ONLY
> those problems to generate the next -rc. If it's O.K., then make it "final".

Other than some quibbling about nomenclature, that's how I see it. We
always had an alpha version for in-house testing only, then a beta for
selected users, which for Linux would be those who have the guts to run
the downloads, and then a release.

I did commenrcial software development for a few decades and that was
usually the practice, and that's what people like Microsoft were doing
when I did a few beta tests for them. I think it's a good model for Linux
stable kernel series.

bill davidsen <>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.153 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site