Hans-Bernhard Broeker wrote:
>On Thu, 19 Feb 2004, Petr Mikulik wrote:
>>Why should we wait till April?
>The April timeline was essentially my invention.
>It's to give "4.0 release candidate 0" (that is, 3.8k) some time to
>settle: let people out there actually download it after we announce that
>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
>allow at least a couple of weeks between 3.8k.0 release and 4.0, there's
>no point doing a 3.8k in the first place. Assuming we can fix all issues
>they find in a matter of days would be unprudent.
>We also have to organize and carry out binary package builds for all the
>important platforms. For the 16-bit DOS/Windows and part of the Win32
>world, that usually means _I_ will be doing it, and I'm not in a position
>to rush things like that, right now.
Who are the "people out there", other than the developers? I guess
there are a few alternatives:
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.
2) Consider the group of developers to be the beta testers.
3) Make a release and let the large group of end users find any bugs.
4) Leave some bugs in so that people have to keep buying an upgrade.
Approach 4 isn't the name of the game here. (Say no more.)
Approach 1 means a group of beta testers is required. Is there such a
group? I could perhaps send a note to the Octave developers list and
ask if one or two people would mind getting the latest release and
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. Unless there are some beta testers out there, I don't see
the sense of this approach. Approach 1 could be a false sense of security.
Approach 2 is what Petr was saying about no bugs being found lately.
That along with the fact that developers here are fairly conscientious
about shaking bugs out means approaches 2 and 3 combined may be the best
one can hope for.
I would argue that the best testing facility we have is to run all the
demos in all the output terminals and verify they are correct. I mean,
last year through a demo I found a really obscure palette bug that took
some while to explain to Petr because the scenario had to be just right.
I doubt any beta tester would have found the bug, or perhaps would have
even realized it was a bug. It seems that almost every new feature that
comes along has an associated demo to go along with it.
>>I've noticed people (including some developers!) get very frustrated that
>>gnuplot gets releases in timescale of several years. That really makes
>>people disappointed. Let's don't do that.
>Let me turn that around by looking at the facts. 3.7.3 is 14 months old
>right now. That's neither so long ago that we absolutely have to release
>something new very soon now, nor is it so short that delaying for another
>month or even two would seem excessive in comparison.
>We are in no hurry unless we impose one on ourselves.
>>I propose to release 4.0 on February 27. Or even better on Sunday
>>February 29, which better follows gnuplot's release timescales :-))
>No, that's definitely too early.
The one month, two month time frame is no problem. However, I think it
is a good idea to settle on a release date and stick to it. This "let's
release in this month" and then two months after that still nothing has
happened is the problem. It is nice to set some goals of what one would
like to have in a certain release and by when it should be made
available. I realize this isn't a commercial software development
venture, but it can be frustrating to work on something only to have it
sit in a 3/4 finished state.
I'm not trying to sound alarmist, but my impression is that Octave
developers may look at Gnuplot as having stagnated. I think I relayed a
note here from the Octave developers list a couple months back of
someone asking when another major release would be done for Gnuplot.
Also, there has been a small degree of discussion on that list of other
forms of graphics drivers for Octave. Maybe I'm exagerating. (Maybe an
industry survey is in order so that we can provide more product value
for the customer's dollar, etc.)