[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Warning: Tree raster can hang you
- To: zzdev@xxxxxxxxxx
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Warning: Tree raster can hang you
- From: Antti-Juhani Kaijanaho <gaia@xxxxxx>
- Date: Sun, 16 Jul 2000 13:51:39 +0300
- In-reply-to: <Pine.LNX.3.96.1000716062129.29778L-100000@fuga>; from lukka@xxxxxx on Sun, Jul 16, 2000 at 06:24:31AM +0300
- Mail-followup-to: zzdev@xxxxxxxxxx
- References: <20000716133404.E14285@xxxxxxxxxxx> <Pine.LNX.3.96.1000716062129.29778L-100000@fuga>
- Sender: Antti-Juhani Kaijanaho <ajk@xxxxxxxxxxx>
On Sun, Jul 16, 2000 at 06:24:31AM +0300, Tuomas J. Lukka wrote:
> The confusion for the users. Even alphabetic ordering goes against
> this scheme. you'll find lots of users downloading 0.9 even though you're
> up to 0.13.
The solution is to highlight the lastest version, and provide the old
releases behind a curtain. Look at how SourgeForge manages the file
releases, for example.
> Any realistic reason?
I find it hard to estimate the "completeness" of the release, or
the closeness to the next "whole" number, or the "bigness" of a step
forward, compared to the whole way from 0 to 1. Thus one rapidly gets
into a situation where one has releases 0.9, 0.99, 0.999, 0.9999, ... or
something else as stupid. I like a scheme where there is no upper bound
for any field.
> Also, there's the semantics: what's 0.1.0 supposed to mean? A big
> step forwards?
MAJOR.MINOR.PATCHLEVEL
is something that is commonly used. Thus 0.1.0 would be the second
minor release, unpatched.
Or:
VERSION.RELEASE.PATCHLEVEL
thus 0.1.0 is the second release of the first version.
--
%%% Antti-Juhani Kaijanaho % gaia@xxxxxx % http://www.iki.fi/gaia/ %%%