On Dec 22, 2010, at 7:47 AM, Branko Vukelić wrote: > > 2010/12/22 Luis Díaz <diazluis2...@gmail.com>: >> >> in particular whenever new versions come out ... I always say ... have >> to wait 1 week or 2 to becomestable ... > > Not "become stable", but "be proven stable". You release, wait for > everyone to give it a go. If everyone is happy, then it's considered > stable, and move to stable box on the downloads page. If someone > complains, it stays in unstable indefinitely, and a new release is > made fixing the bugs.
The problem is that "become stable" is in conflict with "add new features", and the new release that fixes the bugs also gets new (and buggy) features. Linux has a similar problem, that gets addressed a couple of ways. One is that we have Linux distributions independent of (and lagging) the core kernel releases: Red Hat, Ubuntu, etc. The other, somewhat more recent, is that certain kernel releases are maintained by the core kernel developers as stable points. The web2py equivalent would be something like this. Massimo releases 1.91.1, and we (for some "we") decide that that's a good feature/stability set for a stable release point. We then create a stable branch, and somebody (for some "somebody"--this is the catch) back-ports bug fixes to the stable branch, so we have 1.91.1.1, 1.91.1.2, etc, with *only* confirmed bug fixes, no new features, being back-ported. Meanwhile, trunk development proceeds with 1.91, 1.93, etc. Problem is, maintaining stable branches requires real work, and in this environment it means volunteer work.
