> 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 <davidsen@tmr.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/