Dennis Cote <[EMAIL PROTECTED]> wrote: > The knowledge that the new version will be released on a certain date > will comfort most users enough to simply wait (which might also delay > the discovery of more bugs).
Exactly. So in order for these bugs to ever be found, there has to be an official release with no promise of a rapid follow-on. Tragic, but true. > > I'm not sure how much work you go through with each release.... > It takes about 1 days to do a thorough release. Sometimes I cut corners. Notice, for example, that on the current download page some of the products are still at 3.3.8. Doing a release is a non-trivial undertaking. John Stanton <[EMAIL PROTECTED]> wrote: > We were influenced by Deming's work on total quality. He advocates > fixing each problem the moment it is identified and taking great pains > never to ship product with defects. That way quality is maximized, The > short term invonvenience is swamped by the long terms advantages. > In some since, all changes to SQLite are released immediately. Anybody can download the latest changes from CVS or look at the timeline (http://www.sqlite.org/cvstrac/timeline) see the changes and download patches. So source code is released continuously. All an official release does is increment the version number and provide binaries for people who don't are can't compile for themselves. So "release" in the SQLite and open-source world means something very different than "release" for commercial software. In the commerical world, the changes are unavailable until released. For SQLite, a release merely means that the changes are available in a more convenient packaging. How do these varying definitions of "release" effect this argument, do you suppose? -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------