Re: release plane for 4.0 -- Re: GP_ISVAR, GP_FIT_ERRVARS

[Hans-Bernhard B. <br...@ph...>]

On Thu, 19 Feb 2004, Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:

> >it's time for last-minute checking before 4.0 release, run their own
> >tests, and report whatever showstoppers they might find.  If we don't

> Who are the "people out there", other than the developers?  

I'm talking about a publicly announced release-candidate test here.
I.e. we would post to all the relevant mailing lists and newsgroups
that there's a release coming up, and whoever feels like it should
get their package and try it out.  It may be necessary to provide at
least some prebuilt binaries for platforms that don't routinely come 
with a C compiler (DOS, Windows and OS/2, e.g.) at SF.net.

> 1)  Wait a couple months while the "beta testers" try it out and find 
> some bugs before releasing to the large group of end users.

A couple of weeks will be enough to that, I guess.  Easter is in 6 weeks,
which is in about the right timeframe and a nicely memorizable date.

> 2)  Consider the group of developers to be the beta testers.

That would be pointless, I think. We've all been running this stuff
routinely for ages --- the remaining ugly bugs, if any, will now be hidden
in places where none of us ever looks.  We need external eyes and
exercises for that.

> 3)  Make a release and let the large group of end users find any bugs.

That would be the usual approach in open-source projects, "Release early,
release often".  Unfortunately, releases of gnuplot are tricky enough to
organize to make this a non-option.

> Approach 1 means a group of beta testers is required. Is there such a 
> group?  

No. We'll have to go public and call for volunteers for that.

> testing it for a couple weeks.  But I don't think we could ask them to 
> keep getting updates, so it would have to be fairly close to the actual 
> 4.0 release.  

I don't think we either should or can have more than one, maximum two such
release candidates.  I.e. we'll informally declare 3.8k (to be released
ASAP) as release candidate #1 and call to the user mailing list for
pre-release testing of that.  An RC #2 will only be made if we get so
swamped in bug reports that we must assume the fixes for them will break
something else or interact with each other.  Otherwise, we fix what is
found, and I bundle up a release tarball.

>  I doubt any beta tester would have found the bug, 

You just disproved yourself by counter-example.  You yourself were the
beta-tester who found it. ;-)  You may not have started out to do it with
the term "beta-test" in mind, but that's essentially what you did.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.