---------- Original Message ----------------------------------
From: Bill Moseley <email@example.com>
Date: Thu, 11 Apr 2002 10:23:46 -0700 (PDT)
>Colin just suggested calling it 2.1-pre1. That's fine. Or just 2.2.
>My guess is that 2.1-dev is probably as bug free and well tested as any
>previous "release", so why not make the admins happy and go 2.2?
All I'm saying is that every once in a while, make sure that one of
your releases compiles and basically works. You can call it whatever
you like, but with a plethora of search engines available, if
you don't provide something that is guaranteed to compile every once
in a while your user base will go away.
>For small open source user-supported programs like swish I wonder if
>the system of "releases" is out-dated.
I think a release is a completely arbitrary decision that developers
make. They say, "Okay, we're either bug free or we can live with
the bugs that we know about. We document it up, package and give
it a number." Then as you develop on the "new" version, you keep
track of bugs that are submitted and fixed and publish that info
so users can decide to try and use a development snapshot to scratch
their particular itch, or wait for another snapshot.
Another approach is that the development version is way ahead of
the stable version, and subsets of patches are backported to
create new stable versions. But that usually requires two sets of
developers (stable backporters and developers).
The open source philosophy is release often and early. But that assumes
that users can actually build the releases, and your current CVS
snapshot process prevents that.
>So, would a few people be willing to review the docs? You don't have to
>be an expert swish user -- and in fact it's better if not. There isn't
>really that much to review.
I'll start with the docs, but no promises on the examples.
Received on Thu Apr 11 18:12:31 2002