[nSLUG] Jigdo File
synrg at sanctuary.nslug.ns.ca
Wed Mar 5 11:39:37 AST 2003
On Wed, Mar 05, 2003 at 11:04:14AM -0400, Donald Teed wrote:
> On Wed, 5 Mar 2003, Ben Armstrong wrote:
> > and the bottom line to worry about. You probably see many more conservative
> > (< 1.0) release numbers in volunteer-run free software projects because
> > developers are *honest* about their estimation of the completeness of the
> > project.
> I am going to go out on a limb and say they are wrong with their
> versioning. Less than 1.0 traditionally means beta. Beta to some people
> means new. To me it means broken. If they want to add more features, they
> can always do so for 2.0, 3.0, etc.
Readjust your set. It does not mean broken. This is a misconception
perpetuated by dozens of whipped-together projects that appear on freshmeat
and elsewhere that really never should have been made public in the first
place. The version# of these projects is irrelevant. Some of these
projects may well be >1.0 because the developers have their own equally
private meaning for what "1.0" is (most often "this is the first release of
my software") The common theme is that the developers didn't give any
thought to proper testing, debugging and QA before they went public. To me,
a release isn't a release until the software is useful at least to some
subset of users.
> We need some consistancy, and I don't
> believe this has to be different for open source than for commercial.
Shaky limb. You asserted "version# less than 1.0 means ..." and then
explained your own private meaning, not one commonly accepted by everyone.
You say here "traditionally means beta". Sorry, it may be a commercial
software "tradition" but it's also a commercial software "tradition" to
overinflate version#s and release buggy crap to the world as a "final
release" before it's really ready. Why not be honest instead? "We need
some consistency?" Bah. Who is "we"? When I volunteer to develop free
software, I develop it in a way that makes sense *to me*. And while I also
like my version#s to convey some sort of information to the user, ultimately
it is up to me to decide when the "1.0-ness" of my project has been reached.
When my TODO list is still the length of my arm, you're damned right I'm not
going to announce it as 1.0.
As a software developer with some projects myself, I can imagine announcing
"I'm releasing this as verison 0.1 because I'm still thinking of new
features to add to this, and am not entirely certain that I won't change the
API too." Yet I endeavour to make every release bug-free, otherwise I
wouldn't be making a release. I generally don't whip off some half-assed
buggy crap and say "here it is, it's probably buggy, but I can't be bothered
to do my own testing and debugging, so have at it".
Let's take a specific example of a project I'm working on: alibi. See
alibi.nslug.ns.ca. After several 0.0.# releases, some of which had some
pretty gross bugs in them, this project is now at 0.1. I believe that at
this point it's a pretty decent first crack at it. There are a couple of
unhandled exceptions in there that need to be fixed (e.g. a telnet
connection failed, or it succeeded but the list of books on a patron's card
is empty) but aside from that, this software runs on my account, my wife's
account, and John Cordes and his family's accounts. Is it reliable enough
to use every day? Yes. Is it finished? No way. It only handles two local
library systems. It doesn't handle any libraries that only have a web pac,
and the API is constantly in flux.
So back to my original objection: does a version# <1.0 mean "unfit for a
particular use"? Emphatically no. Version# <1.0 even if it *does* mean
beta, or even alpha, does not mean the software is shoddy. Plenty of really
good software is "not finished yet" and has a low version number to reflect
that, yet at the same time is finished enough to be useful for at least some
subset of potential users out there.
,-. nSLUG http://www.nslug.ns.ca synrg at sanctuary.nslug.ns.ca
\`' Debian http://www.debian.org synrg at debian.org
` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
[ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
More information about the nSLUG