[Scummvm-devel] 1.0 or not 1.0? (was: ScummVM 1.0.0 release schedule)
Eugene Sandulenko
sev at scummvm.org
Sun Jul 12 10:51:20 CEST 2009
Hi guys,
So far, I see 2 main opponents, those are Kirben and LordHoto.
The only common thing between you is that we need more testing. DrMcCoy
is also mentions this. Rest of the demands vary quite much.
Thus, my current stance on the question is:
- We still will stay with 1.0
- Release date will be dependent on the testing
That is, I pre-allocated 1 month for testing, but if by end of that
time there will be games which are not tested, I will push the release
date forward.
For the testing, we will require that each game will be tested at least
once. Also it would be not bad if each developer would test a game or
two.
Now on to your replies:
On Sun, 12 Jul 2009 12:22:36 +1000
Travis Howell <kirben at optusnet.com.au> wrote:
> Personally, I would rather at least one more beta release, before
> moving onto ScummVM 1.0. Which would give time, for other worthwhile
> code (GSoC 2009 tasks, patches) to be integrated into trunk in the
> meantime.
As you correctly point out, the activity at testing period decreases
with each release. Stretching this into many interim releases will not
help it, on the contrary.
On Sat, 11 Jul 2009 17:57:53 +0200
Joost Peters <joostp at 7fc1.org> wrote:
> A 1.0 release will make a big difference in the user's perceived
> quality of the software, whereas it makes absolutely no difference to
> us developers.
That is what I think too. I expect that releasing 1.0 will bring more
user base, and thus, testers to the software.
On Sun, 12 Jul 2009 12:22:36 +1000
Travis Howell <kirben at optusnet.com.au> wrote:
> Will the event recording really help play testing that much though? a
> person would still need to watch through each recording for visual
> errors
No, current specs on that feature include making screenshots
periodically and comparing them with current screen output. There are
additional means for helping _automated_ testing, but I would rather
post it separately.
That is, my dream is to have a pack of game recordings which I can run
overnight and in the end get list of passed and failed ones with
gameplay time of errors designated for each failed case.
> I would disagree these are the least popular games, I expect these
> games would be more popular with younger kids, especially on
> platforms not originally supported. We get frequent reports of any
> issues or unknown versions of any HE games too.
:) You know my love for these games, and technology-wise they are one
of the most advanced in ScummVM now. But majority of our users (and
even developers) would not agree with you and me.
> A better example of a least popular game would be Waxworks, which has
> been very difficult to get feedback on.
A truly yuck-ee game.
> Overall the addition of current 16bit color support, adds the
> following HE games as completable or playable:
It was mentioned in the past that we'd better release current feature
set, and only /after that/ integrate 16-bit support. The main reason is
our backend developers.
> It we are having a major release, I don't see how we can state the
> tools are still 'mostly unsupported'. I thought we already provided
> full support for the various tools though.
I quoted our website. Heh, and now I see that my memory served me bad.
We do not have it there, at least now.
> But it would be good if we could do our best to ensure all currently
> supported games are stable, before an eventual ScummVM 1.0 release.
Double testing could help with this.
Eugene
More information about the Scummvm-devel
mailing list