Glynn Clements wrote:
GRASS has never seriously adhered to the odd/even rule. All GRASS
releases are development releases.
Perhaps, but that doesn't mean we shouldn't try.
And FWIW, 5.0.++, 5.4.++, 6.0.++, and 6.2.++ are/were less buggy and
more predictable than 5.3.0, 5.7.0, 6.1.0, and presumably 6.3.0
releases.
It's more accurate to say:
x.y.0 = unstable; has only been tested by developers
x.y.1 = less unstable; has also been tested by users
x.y.2 = even less unstable; has had even more testing by users
And so on.
Yes, but it is nice to let users know that beta (x.odd.0) releases will
probably never advance to the mature x.y.1 or x.y.2 state and so are
not a good target for long term production use where reproducibility of
results and sync'd help documents are an important consideration.
FWIW, I don't see any problem with including totally unstable
features in a "stable" release, so long as they don't destabilise
the rest of the system.
My concern with that is that new users tend to judge the quality of the
entire software package based only on the info they have. If they try
out some new module (like r.in.wms) and it's buggy..... If you can't
trust some specific part of the overall, what parts can you trust? Only
with experience will they discover the majority of the core code is
rock solid*. The trick is to keep them around long enough to appreciate
that.
This was always a problem with GRASS 5 when installation was the
hardest step. I am glad to observe that this seems to have now moved
past that and the <ESC><ENTER> startup weirdness and onto
d.rast-needs-g.region- first type issues.
[*] when was the last core raster map library bug anyone remembers?
even if you include the more modern FP and NULL components? (but not
new modern issues like LFS)
Just read any new linux distro review/test drive to an example of
judging a bigger thing based on first flaw found. It's dumb, but it
happens every day.
IOW, the difference between stable and unstable is whether we're
allowed to break stuff which used to work, not whether we can add
stuff that doesn't entirely work.
The "bug fixes only" policy of restricting new features from stable
releases (x.even.z) ensures that the number of bugs in the stable line
will monotonically decrease and your above mentioned .0,.1,.2
progression will hold true.
E.g. between x.y.z and x.y.z+1, everything which used to work still
works. Between x.y.* and x.y+1.0, some non-critical features may
cease to work or may behave differently. Between x.* and x+1.0.0,
everything is open to change.
Exactly, although I'd emphasize that between major versions (x.*)
"everything is open to change" specifically includes the data file
formats which are otherwise frozen.
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping