Nobody was criticizing the Firebird developers or the Foundation. I was
commenting on the odd situation that the current official stable release
corrupts my client databases, because of a bug which was fixed a couple
of days after that release.



I am much happier explaining to my clients that they have a problem
because of an application bug, than explaining that their database is
corrupt because of a problem in Firebird. Database corruption gives
them the heeby-jeebies, quite apart from the down-time it involves.



So we have a dilemma. Should we update all our clients to an "unstable"
release, with the theoretical possibility that it contains other errors,
or should we just hope there are not too many more database corruption
incidents before the release of 2.1.3?



The expectation of perfection can be applied to various aspects of the
release process. It is not that anyone is expecting perfect software.
But if it is a rule that nothing can be released unless it has been
fully tested, and has gone through a final "perfect" RC phase with zero
changes, then this is a degree of perfectionism which may be detrimental
to the reliability of the product that people are actually using.



Roger Vellacott

Passfield Data Systems Ltd.















From: Firebird-general@yahoogroups.com
[mailto:Firebird-general@yahoogroups.com] On Behalf Of samsoftus
Sent: 12 June 2009 17:52
To: Firebird-general@yahoogroups.com
Subject: [Firebird-general] Re: Updating FB2.1.2 download








I have no trouble with Firebird. I love the product. It seems to me that
the word "stable" is being confused with the word "perfect". No software
is ever perfect. There are simply to many scenarios. Keep in mind that
most software does not "guarantee the software for a specific purpose".
If your specific purpose is causing you trouble, report the problem and,
hopefully it will be corrected in the next stable release. I think the
FB dev team does a wonderful job, especially considering the product is
FREE. If we only released perfect software, MS wouldn't exist.
Sam

--- In Firebird-general@yahoogroups.com
<mailto:Firebird-general%40yahoogroups.com> , Mark Rotteveel
<Avalanche1979@...> wrote:

>
> That is exactly the issue with release management terms like 'stable'
> release: it is only stable in the sense that the code is not going to

be

> changed under the same version number. The issues you are experiencing

> are also called unstable, but that is not related to the specific use

in

> release management.
>
> So under certain conditions a 2.1.2-stable (and any other 'stable'
> software program) can be unstable when run, that however does not mean

> that the 2.1.2 version should no longer be called stable.
>
> It is probably this linguistic confusion why some software vendors use

> terms like RTM (Release to Manufacturing), FR (Final Release), GA
> (General Available) or prod/PR (Production ready).
>
> Of course the theoretical expectation is that a 'stable' version (in

the

> release sense) should generally not exhibit stability issues like
> crashes. Unfortunately in a practical sense testing can never cover

all

> potential testconditions: there are just too many variables (eg
> platforms, clients, datasets, schema designs, transaction usage,
> concurrency numbers and much more) resulting in a combinatoric
> explosion. And as a result in practice stability issues can (and
> generally will) occur.
>
> And even if you have found certain bugs, you may have to make
> concessions because 1) the release can or should no longer be

postponed

> (and the finding is deemed not critical), 2) the testcondition leading

> to the bug is expected not to occur in production (although Murphy's

law

> tells us that 9 out of 10 people will experience that exact problem),

3)

> fixing the bug can result in more severe problems and can better be
> addressed in a future version, ... (there are more reasons).
>
> Mark
>
> Roger Vellacott wrote:
> > I had indeed misunderstood the meaning of the word "stable". I

assumed

> > a stable version was a version which didn't crash.
> >
> > So I guess you are telling me that the 2.1.2 official release is

stable,

> > even when it crashes.
> >
> > Roger Vellacott
> > Passfield Data Systems Ltd
> >
> >
> >> I think you have the wrong impression of what the term 'stable'

means.

> > 'Stable' indicates that there will be no more changes to a version

and

> > that the >testing has formally been completed. Version 2.1.3 is not
> > stable yet because 1) there could be code-changes to bug-fixes or

new

> > bug-fixes and 2) testing >has not been formally completed. On the

other

> > hand, version 2.1.2 will not be changed (under that version number)

and

> > testing has formally been >completed, therefor it is considered
> > 'stable'.
> >
> >> So if you want to have a fix for the bug you are experiencing in

the

> > 2.1.2 stable, you will need to use a 2.1.3 snapshot which by

definition

> > is >unstable.
> >
> >> As there will always be software bugs, even in tested versions of
> > software, the word 'stable' does not indicate that a program is
> > bug-free. Software is >NEVER bug free (except for small programs).
>
>
> --
> Mark Rotteveel
>

[Non-text portions of this message have been removed]