[Scummvm-devel] ScummVM 0.14.0

Travis Howell kirben at optusnet.com.au
Sat Jul 4 14:09:24 CEST 2009


Max Horn wrote:
> Am 04.07.2009 um 12:10 schrieb Travis Howell:
>> Could the planned release cycle for ScummVM 0.14.0 be delayed a few
>> weeks longer, in order to wait for merger of 16bit color support?
>>
>> 16bit color support will add a few more games (Freddi Fish 5, Pajama
>> Sam: Games to Play on Any Day, Spy Fox 3), and is planned to be merged
>> into trunk in the near future.
> 
> It is ???
> 
> I would have thought that it won't be merged before the end of GSoC,  
> i.e. *soonest*till August 10, probably later. At that point we'll have  
> very little testing.
 > So, if we wait for that, we need to delay by at least 2 months.

A release cycle is due to start soon, with the branch added not long (1 
week) after the release cycle starts.

It was mentioned on IRC, to merge 16bit color support, as soon as 
ScummVM was branched for the next release.

August is only a month away, and the play testing for ScummVM 0.14.0 
could be used to thoroughly test 16bit color support.

> Personally, I'd very much prefer not to do that, and then make a new  
> release after that around Christmas.

The last release cycle (0.13.0) was 1.5 months, with a minor release 
(0.13.1) two months later. So I think another major release before the 
end of the year, would be pushing it, especially if delays are required 
by developers for any reasons.

>> Merging sooner, means that 16bit color support could be more  
>> thoroughly
>> tested (especially for regressions) during the play testing phase of
>> ScummVM 0.14.0.
> 
> Yes, but the feature is not done, and the API is IMO still not quite  
> done. So I am definitely against a hasty merge, which this seems to be  
> the case here to me.

Well it sounded like the 16bit color task was near complete, with only 
documentation and then testing to go, judging by recent comments on IRC.

>> Porters are usually more active during the release cycle for  
>> ScummVM, so
>> it could possibly help speed 16bit color support in the various  
>> backends
>> too.
> 
> In my eyes this is another argument against a hasty merge now: Let's  
> get a release out now with all the other improvements, without  
> complicating it by porters by having to look into adding 16 bit  
> support. Save that for another release cycle, resp. give them more  
> time to prepare for it before a release cycle.

Well it will be an optional feature, so up to porters whether it should 
be supported at this stage or not. That is why I stated 'possibly help 
speed' 16bit color support.

> A release cycle is a *bad* time to add new features to backends, in my  
> eyes. Even though that is frequently when porters do it, but that  
> doesn't make it better.

True, but it continues to happen, and might as well take advantage of that.




More information about the Scummvm-devel mailing list