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, 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
>