I totally agree with Jonathan Lundell, I think the changes he proposes, would provide stability web2py, and I'm sure will appeal to users (both new and existing).
My humble opinion is that the way they attack the bugs, is one of the weaknesses ofweb2py, I think it is messy and I'm sure many have decided not to use web2py for it. 2010/12/22 Jonathan Lundell <jlund...@pobox.com> > 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.
