[Scummvm-devel] 1.0 or not 1.0? (was: ScummVM 1.0.0 release schedule)

[Johannes Schickel]

Eugene Sandulenko wrote:
>> Our public testing is unfortunately more lacking with each new
>> release cycle. With nasty regressions still passing through our
>> testing stage, and only found later (often too late). I expect this
>> will continue, until most game engine are complete, and no longer in
>> such active development.
>>     
> No, the main problem here is that people just get tired of testing same
> games over and over again. Sometimes our core changes could break
> existing engines, so even if the engines themselves would be stable,
> testing is required anyway.
>   

Actually it might be true that people are annoyed by testing all the 
time. And that we will still have the chance for regressions on core 
changes. But that is no reason that we should now release 1.0.0 anyway 
IMHO. At least not if we can assure *all* games tested this time. 
(That's the minimum I would want for a 1.0.0 release).

> The only solution I see is that we really /have/ to finish
> implementation of the event recorder. I will do my best in this regard,
> but any help is welcome.
>   

Yeah the event recorder would be nice, still our current event recorder 
approach a some problems IMHO:

* it relies on the number of EventManager::pollEvent calls, thus if a 
engine would add another place where it's called, all recordings would 
be broken

* same goes for delayMillis

* and of course the random number generator

Of course we might not have any easy way to fix that, when we only have 
the event recorder on the 'backend' side.

I did refactored the code out of DefaultEventManger (see my mail to 
devel about my EventManager cleanup). I guess with that it might be 
easier to do some hooks in the engines too, which might be useful, 
depending on the approach we use for the event recoder IMHO.


>> The recent progress on MM Apple/C64 (see patch tracker item), and on 
>> sound support for Amiga version on the Secret of Monkey Island would
>> be well worth waiting longer for too.
>>     
> As you know, those came completely unexpectedly, without any prior
> planning. The fact is that being volunteers we cannot expect anything
> to be implemented by date X. Thus, we're IMHO in a dead loop with this.
>   

True we are volunteers so we can't expect it to be done on date X. But 
we can also just delay a major release as 1.0.0, till we have the 
feature we think we should have.

 From what I remember for example, where had been always questions about 
Monkey Island 1 Amiga music in the past. I think that's a really nice 
feature we should wait for before releasing a version a 1.0.0.


>> With the GUI wizard interface task of GSoC 2009 progressing well, it 
>> seems well worth waiting for the results. Which will make it much
>> easier for users to use the features (especially sound compression)
>> offered by our various command line tools.
>>     
> This is valid point, still our tools always were "Mostly unsupported"
> and I don't see how we can improve that.
>   

Think the tools GUI would be really nice to have for a 1.0.0 release.

>>>   - GMM
>>>       
>> Which still isn't quite complete, or completely handled by all game
>> engines.
>>     
> Right. And again, there are no development in this area, and I am not
> sure that my call to make it will guarantee any results within release
> timeframe.
>   

Well some engines might not completely handle it anyway. I thought for 
example GOB and AGOS can't ever support the save/load features.

IMHO the major drawback of the GMM is that engines can't add custom 
dialogs to it. That is for example nice for SCUMM, it could just add the 
help dialog to the GMM and then it should be fine to drop the SCUMM 
internal dialogs and only use GMM for it.


>> Whether we are still beta quality is debate, with many of our game 
>> engine based off reverse engineering in many ways. It is difficult to 
>> know what still could be missing, or isn't quite right, and what bugs 
>> may still have not been found (even after all this time).
>>     
> IMHO we will never have _all_ engines stable. Consider just SCI, I
> think there are several years of development ahead until every SCI game
> will reach at least level of SCUMM engine quality support.
>   

I doubt that'll ever be bugfree for all engines, too.

>> Our core is quite good, along with many game engines (especially
>> those based off original source code). But I still think it would be
>> better to wait longer for the first major (1.0) release.
>>     
> Okay. It is always best to take community decision. Thus, I need to
> hear more from other developers.
>   

I'm the same opinion like Kirben, IMHO we should wait a bit longer.

The keymapper is also a feature I would like to see in "1.0.0" (or 
rather the first 'non-beta release').


>>> Perhaps for 1.5 we will have 16-bit support, DW freewared. SCI
>>> support for 2.0, etc.
>>>       
>> No, those version jumps, sound too high, for too little changes.
>>     
> That was an illustration. After all, those are just numbers.
>   

Yeah true those are just numbers, just like 1.0.0 is 'just' a number. 
And do we need the "1.0.0" number on our next release? I doubt so.

// Johannes