> > Checked my own version and found it to be "Ver 11.16 Distrib 3.23.49".
> >
> > He, version 11??? Quit confused, but after a sanity check with reality
> > I realized I must be using version 3.23. Anyhow, check the status of
> > next version and found out that version 4.0 is in alpha mode...
> The "Ver 11.16" refers to the version of the MySQL *client* utility.
> "Distrib 3.23.49", as you figured out is which version of MySQL it was
> distributed with.
> 
> 
> > Geeeze - not even beta. So I guess even an estimate when the first
> > alpha of version 4.1 is virtually impossible to give right now, or?

> I'll trust a MySQL alpha release before the final production releases of
> most vendors.  In fact, we're using 4.0.1 in our production environment with
> great success.

Its your system, and if you think it worth the risc, it is of course you
decision to do so to, ;) but I would never ever trust _any_ code in an
alpha-development stage. Anyone how does that is likely to get a big
surprise, sooner or later - or they are just very lucky if nothing happens.

Using Alpha-code in a production environment is not only doing a
high risk experiment, but also nothing I never would recommend
someone to do with my honor preserved.

> From the manual:
> 
> *alpha indicates that the release contains some large section of new code
> that hasn't been 100% tested. 

No one can afford, neither in consumed time, nor in money or
resources, to test system components up to 100%....

> Known bugs (usually there are none)

Does anyone more than me thinks that this smells lack of system testing? ;)

> should be documented in the News section.

"should be"... have I ever heard that before? ;)

> See section D MySQL change history. There
> are also new commands and extensions in most alpha releases.

That's the kind of basic idea with Alpha-code, yes....

>L Active development that may involve major code changes can occur on an alpha
> release, but everything will be tested before doing a release. There should
> be no known bugs in any MySQL release.

I'm impressed if they, really, can achieve this goal - which I
of courses doesn't believe in a single second. ;)

> *beta means that all new code has been tested. No major new features that
> could cause corruption on old code are added. 

That's why we call it beta, yes...

> There should be no known bugs.

!!

> A version changes from alpha to beta when there haven't been any reported
> fatal bugs within an alpha version for at least a month and we don't plan to
> add any features that could make any old command more unreliable.
> *gamma is a beta that has been around a while and seems to work fine. Only
> minor fixes are added. This is what many other companies call a release.

So why not call it release to avoid confusion then?

> *If there is no suffix, it means that the version has been run for a while
> at many different sites with no reports of bugs other than platform-specific
> bugs. Only critical bug fixes are applied to the release. This is what we
> call a stable release.

How are the binary distributions of alpha and beta releases complied?
In debug or release mode?

> > But anyway. When could one expect to find a first alpha version of 4.1?
> > Sometimes during 2003? Or?

> The manual makes allusions to an "early 2002" release for 4.1, but I think

Which manual? mysql/docs/manual.txt? I did a text search in that file and
couldn't find "early 2002" nor "2002".

> that's probably slipped somewhat.  

First rule: Every release date slips. ;)

Lemma: If released at correct date, either the software is to
buggy to use, or it misses, important, promised features of
that release. ;)

> Late 2002/early 2003 seems more likely.
> However, be aware that the fact that they plan on having stored procedures
> in 4.1, does not guarantee that they actually will have stored procedures.
> Often times, a feature cannot be implemented as efficiently as Monty et al
> would like, or other features become a higher priority and things get put
> off for a while. (*ahem* sub-selects -- when I started using 3.20.x they
> were supposed to be in 3.21.x, then 3.22.x, then...)

That's strange. I would say that stored procedures is a highly useful thing
to have had implimented in a RDBMS.

        //Anders

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to