Mailing List Archive


Back to the month index Back to the list index
Fernando Maior (fmaior@upol.com.br)
Fri, 16 Apr 1999 15:55:28 -0300 

Message-ID: <371787A0.FB78FCAF@upol.com.br>
Date: Fri, 16 Apr 1999 15:55:28 -0300
From: Fernando Maior <fmaior@upol.com.br>
Subject: Re: more wishes...

Hi List,

That is good talking.

Bye,
Fernando Maior

"James E. Harrell, Jr" wrote:

> Seems that every day or so, people are asking to add feature x or y... What
> this comes down to, is that we really don't have much of an idea of the
> requirements tree Hughes is working with... every month or so for the last
> few months, a bug fix / requirements change / feature addition has been
> implemented and released. While this turn around is excellent, from the
> outside it seems a little haphazard...
>
> Perhaps a design paradyme shift is in order here- I'd much rather wait 3 or
> even 6 months for the next version with all of the new features combined
> and (hopefully) debugged than get a new feature once a month. Better yet if
> I know in advance what all those new features are going to be! Feature
> creap seems to be getting a little out of hand! If I had a production
> server that required patching once a month, I would find the maintenance to
> be almost unmanagable! On the other hand, if I had a list of all known
> features and deficiencies of the current release, I could write my programs
> around those knowing that they may not be addressed for 6 months.
>
> Given the stability of the current release (secondhand knowledge, I don't
> have a production server running yet), I would think it wise to take a step
> back and enter a requirements definition phase for the next major release.
> (ok, *maybe* minor release)- Once the requirements are completed, freeze
> them.
>
> Maybe even give the user base a good look at the requirements prior to
> freeze- and give them a method of requesting requirements additions. This
> way, the next release would have a know implementation that is expected.
> Might take six months to get there, but so be it. It's controlled.
>
> On the other hand, bug fix releases are always welcome. But when a feature
> addition is combined with a bug fix, certain conflicts exist. If my
> programs are not affected by the bug, I won't upgrade the server! But a
> common answer to most questions in this group seems to be "Upgrade to
> Version x.x; it has the features and bug fixes you need" - this should
> *only* be the case with respect to bug fixes, and never the case with
> respect to features. In my opinion, the feature additions should be
> reserved for major releases! Thus, the answer to bug questions should be,
> upgrade to patch version xxx, while answers to *feature* questions should
> be "wait for version XXX".
>
> >From a wider scope, it would be nice to have an idea as to the expected
> future development path. I remember years ago (in some 1.x version
> discussion) hearing that msql will *never* support things like atomic table
> operations (arithmatic or otherwise), stored functions, transaction
> support, record locking, security management, etc. But the more development
> I see with this product, the more realistic those expectations become.
> Better said, with a product so well desinged and supported, the user base
> expectations are increasing! What I'd like to see, is a requirements tree-
> if some day we expect to see row locking in a HugheSQL-Pro, add the
> requirement but assign it to version 5.0! And for those that only want the
> lightweight version, maybe there will be product diversion in the future...
>
> As always, Bambi, keep up the tremendously good work. But don't let us
> corner you into feature additions weekly! Hear our requests, prioritize
> them, assign them importance levels; and put them into a future
> requirements document(s) that shows us when you expect to implement them.
> And give us a new features in six months or even a year! (but keep the bug
> fixes comming!)
>
> Just my $0.03 worth.
>
> .. james