[Scummvm-devel] CVS frozen for 0.5.0!
Max Horn
max at quendi.de
Fri Jul 11 12:22:07 CEST 2003
[I replied to this earlier but apparently by accident sent it only to
Ender]
Am Donnerstag, 10.07.03 um 06:02 Uhr schrieb J.Brown (Ender):
> We just froze for 0.5.0, so please use your judgement in applying CVS
> commits. If in doubt, please check with myself or Fingolfin.
>
> An updated test list will be posted later tonight, I have a few things
> I
> want to change. This is a fairly 'soft' freeze for the first few days,
> to
> allow any commits for V1 support... I still want to get this fixed up a
> little more for 0.5.0, and Beneath a Steel Sky is excluded from the
> freeze.
>
> The planned release schedule is as follows:
>
> Jul 10 - 14: Soft freeze, initial testing of 'frozen' games (Simon,
> DOTT,
> S&M, etc)
> Jul 14 - 24: Hard freeze, strict commit rules
> Jul 24 - 28: Final tests, ensure all ports recognise all games
> Jul 28 - 31: Ports compiled/uploaded, CVS tagged and unfrozen
>
Hm... any reason we are reverting to the old inflexible scheme, instead
of using the modern one which worked so well last time (e.g. unlike
previous times, it was trivial to get out a bug fix release even two
weeks after the original release).
In particular: Why do we hard freeze for ten days, then test for 4 more
days? Why wait 10 days before testing ?!? That makes no sense to me...
Maybe you meant: we hard freeze for fourteen days and test during that
time. That still doesn't make much sense to me, though, since we need
to fix bugs that crop up during the test period. I'd propose the
alternate approach
1) Jul 10 - 14: Final development efforts take place (that's what you
call a "soft freeze", I guess)
2) Jul 14, 12:00 UTC (or any other time): We branch. Major work can
resume on trunk, branch is frozen and only gets bug fixes
3) Same day: We release a "beta" tarball and binaries, and let people
test, for example for 10 days (doing that since SF.net CVS is lagging
to much behind). It's also trivial to have tarballs for the 0.5.0
branch be made, in parallel to the regular daily snapshots
4) Jul 14-Jul 24: Only bug fixes are applied to the branch
5) Jul 24: If things are sufficiently stable, hard freeze the branch,
and maybe test it for a few more days (and maybe provide "RC1"
source/binares). This should be handled flexible: if there are still
major issues open, we can easily delay this point -> this works easily,
since people can still work on the trunk in any way they want, unlike
in the other scheme, which essentially forces developers to "hold
still" for 2 weeks).
6) Day X: Release. The release happens within 24 hours. Ports which are
later are late and can be added later. After all, porters have 2-3
weeks lead time, so they know the day of the release. There is no real
excuse to miss it, and no reason to wait for specific binaries either,
IMHO. If a porters knows he won't be able to provide binaries in that
time frame, fine, we can also adjust the time frame - but that
information should be available in advance. Plus, I don't see any
problems in having a given binary a few days later than others (nobody
complained about that for 0.4.0 / 0.4.1)
To emphasize this again: I believe it is very important that we do not
prevent developers for two weeks or longer from making bigger changes.
E.g. I have the next two weeks time. If I am not allowed to make any
changes, fine by me, I have many other things I can spend my time on.
However, that doesn't mean I'll make those changes after the two weeks,
because then I will probably not have time anymore. I guess it's the
same for other developers: we can't just allocate our time for ScummVM
in arbitrary ways. If we have time to work on it, but can't, that time
is lost forever for ScummVM.
Cheers,
Max
More information about the Scummvm-devel
mailing list