[Scummvm-devel] Bringing our Core Code to another Level?

[Johannes Schickel]

On 08/13/2013 12:42 AM, Thierry Crozat wrote:
> On 12 Aug 2013, at 22:19, "A. Milburn" <fuzzie at users.sourceforge.net> wrote:
>
>>
>> So, the obvious alternative approach is simply for third-party projects to
>> simply fork off a copy of the core and try and keep it in sync as needed
>> (which is what ResidualVM does, for example).
> The remarks from fuzzy bring a question though: will it be possible to
> provide a core that can be used for other games without needing to be
> forked and modified? It looks like Residual for example needed to modify
> that core. How much would we be ready to accommodate changes needed
> by others in the core code? And to maintain them?

I think Residual is not the best example for diversions. We are fixed at 
2D games, while Residual's major changes are for 3D games support AFAIK. 
Such "big picture" changes are nothing we should worry about too much, I 
would say. Trying to handle such things in a generic core would be much 
more work than simply focusing on what is fitting our basic setting 
(i.e. 2D games).

I think a possible way to have others use our core code would be as follows:

We have a repo for our "core". Third-parties will clone this repo and 
integrate their code into it (i.e. add your engines, your logo, 
whatever) and use the result as a official development repo. Whenever 
there are upstream core changes, they can pull them in by, for example, 
merging the upstream core's master into their repo. This is somewhat of 
a "soft" fork when they do not make any changes to our core.

Of course, we need to assure that they will not have to edit files which 
are kept in the core repo to avoid any merge conflicts for "default" usage.

How we maintain changes from third-party projects is a good question 
however. Then again, we can ask developers of third-party code who want 
to merge their changes into our code to maintain them as part of the "team".

> And this also raises the question of whether this will make it more difficult to make changes that will
> break engines, as not only in-tree engines would need to be updated but
> also engines developed by others.
>

I think in an uncontrolled scenario it would be easier to break engines. 
However, in case of ScummVM engines we can still stick to the current 
policy of providing updates to/helping people to update their engines.

In case of a third parties they would need to make sure that they update 
their engines. After all, its still their choice when to update to a 
newer core version. I think it is hopeless to make promises that we will 
adapt all the third party code out there whenever we have some possibly 
breaking API changes.

Greetings,
Johannes