[Scummvm-devel] ScummVM 1.0.0 release schedule

[Eugene Sandulenko]

On Sat, 11 Jul 2009 13:26:10 +1000
Travis Howell <kirben at optusnet.com.au> wrote:

> I'm really starting to get tired of this, where was any recent 
> discussion about making the next release ScummVM 1.0.0?
We discussed it only with Max.

* The manual seems never will be finished, our attempts to make anybody
  work on it failed. 

* Majority of our engines, SCUMM included were stable
  for years. 

* Our product has been used in several commercial releases
  quite successfully:

  - GOG.com
  - SoldOut for Broken Sword 1&2
  - Snowberry for Gob1-3
  - Atari for HE games <cough>

> Considering the initial focus of ScummVM has always been on SCUMM 
> engine, I still think it would be better to wait until all SCUMM
> games (except Moonbase Commander) are supported. The remaining HE
> games are mainly a case of bug fixes and additional u32 code, with
> the addition of 16bit color support in the gsoc2009-16bit branch.
There is nobody working on PCE Loom, Sega MI, MM NES, MM C64, MM Apple,
FM-TOWNS games.

This goal is just unrealistic.

> For ScummVM 1.0, I think we should really considering dropping
> support for older saved games in the SCUMM engine, and starting fresh 
> (Supporting saves from ScummVM 1.0 onwards) too. Several code changes
> in the SCUMM game are limited, due to continued support for older
> saved game.
In any case we will have to provide backwards compatibility. Thus, time
of this change (I hear about it for the first time) does not affect our
release cycle.

> Before the ScummVM 1.0 release cycle, we could compile a list of
> planned changes, drop save game compatibility for short time (few
> weeks?), make the required changes to SCUMM engine, and only offer
> saved game compatibility from that point onwards.
You can easily do it for 1.5, 2.0, whatever.

> Also what happened to the required manual, before a ScummVM 1.0
> release?
Yeah! That was the _single_ point till now which prevented us from
announcing 1.0. But waiting for 2 years with little changes in this
aspect shows that we cannot rely on this.

> Another important point, the tools are still lacking a decent GUI,
> which I think would be essential for a non-beta release too.
Tools never were a priority for us. Usually they're one shoot usage per
game. GUI is nice and desired, but so far even command line utilities,
being decently documented served its purpose.

Besides, which makes me wonder, what will happen with our tools builds
for other platforms once GUI is there? Will command line utilities stay?

Adding DW support is pretty big milestone. With 1.0 we will also have:

  - GMM
  - New GUI
  - Faithful Adlib emulation
  - MPEG2 support dropped

To name a few.

We were not beta for a long time now. Thus, we decided to change the
numbering scheme. And yes, it is just numbers, nothing will change in
our release cycle.

Perhaps for 1.5 we will have 16-bit support, DW freewared. SCI support
for 2.0, etc.


Eugene