[Scummvm-devel] Towards a new release branch model
Max Horn
max at quendi.de
Tue May 31 11:57:33 CEST 2011
Am 31.05.2011 um 11:38 schrieb Marcus Comstedt:
>
> Max Horn <max at quendi.de> writes:
>
>> Good question. I have no good answer ready right now, but apparently, the git team itself somehow deals with it. So it would be a good idea to find out. E.g. somebody could ask them.
>
> git does not have time-based releases, and they spend forever
> reviewing every minute change, so I guess they'd just postpone the
> release indefinitely while they come up with a "slow fix" they are
> happy with (or more specifically, that Junio is happy with).
Well, they do have releases every couple weeks or so. It's hard to imagine that they never find a bug in 1.x.y.z that ought to be fixed in 1.x.y.(z+1), right away, but for which a "proper" fix requires a substantial change that is not desirable for that. But maybe that just never happens to them due to incredible luck / planning. Or do they simply refuse to fix urgent data loss bugs as long as no "proper" solution can be implemented, even if a hotfix is known?
>
>
>>> I seem to recall there
>>> were some problems with using this flag for additional things, but
>>> maybe that's been fixed with the restructuring of the configure
>>> script?
>>
>> I wasn't aware that there ever was a problem with that, nor do I see one now.
>
> The problem was related to altering the behaviour of
> --enable-all-engines depending on the value of --enable-release, IIRC.
The problem with that is not really that we can't (or couldn't) do that (I haven't looked at it and how much work it would be, but obviously it can't be that hard). The problem with that was that changing the behavior of --enable-all-engines based on --enable-release seemed highly undesirable to some people (e.g. me).
Bye,
Max
More information about the Scummvm-devel
mailing list