Hi Folks, I just read the entire thread... uff.
I am a member of the Technical Leaderhip Council at Coin-OR (www.coin- or.org). We went through these arguments a while back improductively several times until we made it a priority to resolve them. We are sure glad we did. We have over 50 projects in diverse areas of Analytics, some with very enthusiastic innovative project managers and some with very conservative codebases sponsored by IBM. Our users are just as diverse (as is the case with web2py). Here is what has worked for us (it is not that different from many other projects): 1) Stable means feature-stable, not necessarily crash-stable. They take numbering schemes like X.Y 2) Releases use minor points derived from stable numbers, e.g. X.Y.z. All releases must pass their unittests. Unfortunately many projects have incomplete unittests, but that is another issue. Releases have bug-fixes only. 3) Trunk is trunk. Use at your own risk. That is where the latest and greatest lives. 4) Each project has a ticket system for patches and bug reports. The +: * Users knows where the project stands. They know what they are getting from their downlads and naturally segment into the appropriate groups. * PMs can more easily coordinate developers. The -: * It is often difficult to get PMs to do stables and releases. Sometimes it takes a dedicated non-core developer who really wants a feature to do it for them. Personally I think a ticket system for web2py linked to from the "Support" tab would be a great first enhancement (I added it to the voices app). Cheers, Leo. On Dec 30, 5:55 am, appydev <appy...@gmail.com> wrote: > 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. > >
