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

[Max Horn]

Am 14.07.2009 um 05:24 schrieb Travis Howell:

> Max Horn wrote:
>> Some people here have listed features that they believe should be in
>> 1.0.0, that we should wait for before going there. I strongly  
>> disagree
>> with every single one! We can *always* find one more thing to add. In
>> fact, this is why so many projects and commercial applications run
>> over their schedule: There is always one more thing that would be so
>> cool and so easy to add. Well, yes, but somewhere you have to make a
>> cut. You shouldn't cut on usability, of course. I am talking about
>> *features* here. And of those we have enough, and had enough for  
>> long.
>> To me, the best possible user experience was always the only reason
>> not to go to 1.0.0 yet. We will try to address that by working on
>> docs, by improving our release process, by improving quality
>> assurance. But adding features (or waiting for feature to mature
>> enough to be ready for inclusion) is exactly what we should *not* do
>> at all.
>
> Then another reason, as mentioned in my other recent message:
> Daily snapshots of ScummVM SVN have been limited to only a few  
> platforms
> in the past though, which meant many ports didn't get as much testing
> over a longer period of time. With buildbot that has expanded to cover
> many more platforms (with Dreamcast just added), so we definitely  
> could
>  benefit from a longer time period before ScummVM 1.0. In order to  
> give
> other platforms are much more thorough testing, over the time (several
> months) between this release cycle, and the next release of ScummVM.

What you say fully supports my stance in my eyes: Don't add new  
features now, rather branch of 1.0.0 soon and then concentrate on  
polishing and fixing that branch. Possibly over some months, to give  
ports a time to get polished. Add no new features to the branch in  
that time, as that would invalidate any testing already done.

I am confused why you seem to think what you said supports adding more  
features... ?


>
>> Support for more games, virtual keyboard and key remapper working
>> everywhere, MI Amiga music support, 16bit game support -- all cool
>> features. All worth working for. For version 1.1, 1.2, 1.5, 2.0,
>> whatever. Not for 1.0.
>
> Expect this isn't just waiting for 'feature X' or 'game Y', as I
> previously mentioned in other message. Of the items I have previously
> mentioned, only u32 code for HE games will take awhile to complete,  
> but
> no more longer than the next release (after this one).

I am not sure why this is not yet another feature X :). Anyway, if  
it's ready that soon, I look forward to it in 1.1, or 1.2, or whenever  
it is ready :).


> 16bit color support and sound support for the Amiga version of the
> Secret of Monkey Island are available now, but only in separate
> branches.

Two more features X2 and X3. Both still in need of polishing and  
completion, then merging (which *will* include resolving regressions,  
I am willing to make a bet on that). And *then* some field testing.  
Waiting for that would delay the start of the 1.0 *testing phase* by  
some months.

BTW, I am somewhat unhappy about the lack of detailed status reports  
by nolange (and his mentor) on the Amiga code. The blog posts are very  
brief and lacking in detail. What exactly works, what not? Have the  
ugly hacks been resolved that were used to graft the player code to  
the SCUMM engine? What is the current schedule / timeline for the  
project (I couldn't find this on the blog). This lack of reliable  
information by the code author (and the mentor, too ;) in my eyes  
makes it unsuitable for inclusion in the next release.


> The animation patch for Apple/C64 versions of Maniac Mansion
> is currently available on the patch tracker too.

Nice feature X4

> The GUI support for tools is still in progress, but with a set  
> timeline
> (10 August for end of GSoC). Which is less than a month away now,  
> which
> is more than enough time, to include in next release (after this one).

Nice feature X5 -- but actually, one we can *maybe* include in 1.0.0,  
since the tools can get a different release cycle than ScummVM itself;  
for one thing, there are much fewer platforms we need to test them on.

However, I am not *overly* optimistic right now. The GUI code seems to  
start getting into shape now. However, the branch still has some  
*serious* issues -- I am talking about compression tools not working  
correctly anymore in it. Sadly, Remere seems to perform no regression  
testing at all, although I asked for this from the start. Anyway, I  
now asked him yesterday to outline how he plans to deal with that (one  
proposal of mine was to start building a testing tool for the  
compression tools: have a table/"database" with tuples of input files  
+ MD5s + sizes, which tool to use on them (with which command lines),  
and then a list of outputfiles + MD5s + sizes. That could be done to  
perform automated testing (a test would be skipped if the input files  
are not there, so even if you don't own all games you could perform  
tests). There are other ways to ensure that the tools work, of course.

But again, this means that the GUI code is under heavy development. We  
should not wait for it now.

>
> In my case, I'm only asking for one more beta release, before we  
> finally
> go to ScummVM 1.0.

We always ask for one more (beta) release. In half a year, five new  
cool features and maybe some engines will be "almost done". Do we add  
"one more beta release" then? Where do we draw the line? I say, we  
should draw it here. For no good reason other than there seems to be  
no good reason for any other place, either ;).


That said, yes, we definitely should take longer for this release; we  
should have a 1.0.0rc (or 1.0.0beta if you prefer the name) before  
that. As I said, essentially, 0.14.0 -> 1.0.0rc and 0.14.1 -> 1.0.0  
and 0.14.2 -> 1.0.0


Bye,
Max