To: Phil Nelson <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/03/1997 12:33:30
>HOWEVER, I will say this: the next release is likely to be worth
>it. We'll have the bus_dma stuff fixed (which will fix bounce buffer
>issues now and forever on all architectures), probably real PCMCIA
>support, probably real ATAPI support, far improved VM, etc., etc.
>Would you call these changes big enough to warrant a 2.0 instead of
I might :).
But that's just an invitation to kick out a `1.3' release earlier:
declare a code freezeimmediately before the bus-dma changes go in,
start a `release cycle', and then kick out a 1.2E-ish `1.3' in about
I *like* the idea of a -stable release. Maybe we could make it work
by always having a `release cycle' in progress; -stable is then just
the frozen, release-bound code. Users can choose whether they want
-stable or -current.
If we stuch to release timetables, that could give a release about
four times a year. But that probably isnt' realistic. Allowing time
for alpha and beta testing -- and developer bandwidth! -- we might be
able to do it twice a year, rather than four. But that gives a lag of
at most six months between `stable' releases, support for new drivers,
I think reducing the time lag between new functionality in -current
and ``stable'' releases (from the current major-release rate, down to
six months) would be useful for everyone, both users *and* developers.
The question is how to do it with the resources we have available?