I think the issue can be solved by labeling releases and posting older - more stable - releases.
This is what I do now: - I always work on trunk - trunk is very unstable - Once in a while when trunk is stable I post a "nightly build" which is more like a release candidate. It does not change nightly, but more likely weekly as more and more features are added. - When I have no open issues AND I am happy about the nightly built, I post it as stable. - The first stable is usually 1.xx.1 - this is when problems usually starts... 1) one problem is occasionally build errors that may affect GAE, Windows or Mac 2) one problem may be bug in new features that were not very well tested 3) one problem may be that new feature break something that use to work (thisis the thing I am mostly concerned about. It happens for very obscure features that few users are using and hard to discover until a major release) Anyway... - the 1.xx.1 is followed by 1.xx.2 and 1.xx.3 and ... 1.xx.N during a short period of time (within 48hrs). These are all bug fixed releases and no new features are added. They usually fix 3) completely in <48hrs. Usually is there is only open ticket remaining it is about a new experimental feature OR a pre-existing issue. - keep all previous 1.XX.N versions that had a relatively long life in http://web2py.com/examples/static/1.XX.N/web2py_src.zip - I delete the 1.XX.m with m<N for space. ----- I could post links to all previous versions. Nothing wrong with that. But the more people hold on old version instead of moving to 1.XX.1, the less likely bugs will be discovered and fixed in <48hrs. ----- 1.90.1 and later versions are a big of an exception. They included the new DAL. That means that from 1.89 to 1.90, 5000 lines, ~25% of the entire web2py python source, code were completely rewritten! Some of you may look at the 4-5 bug reports that we fixed in 1.90.4 and say "those 5 bugs had to be caught before!". I look at it and say "How can it be we rewrote 25% of web2py, from scratch, and we had only 45 backward compatibility issues? And we managed to fix 4 them in 48 hours?" (one is still open and will be fixed soon). The only times when we had a change of comparable importance is when Thadeus rewrote the template engine and when Jonathan rewrote the routing module, those too went very well. Anyway, the point is. We are not going to have a jump of this magnitude again for some time. Most of the new released have a smaller set of differences and therefore are less error prone. Massimo On Dec 23, 6:55 pm, weheh <[email protected]> wrote: > Massimo, good news. Web2py is successfully being adopted by more and > more developers who are using it for very serious purposes. It's going > viral. Therefore, there need to be at most a few major releases a year > and a bunch of incrementals in-between. > > I anticipated a challenging release with the latest DAL changes. At > enterprises where I've worked in the past, changes to the db layer > were always considered major releases. That's when the troops were > mustered to test en-mass before pushing the product out the door. > > Web2py quality must always be of paramount importance. In the absence > of a delegate, we look to you to lead this issue. It almost goes > without saying that doing it right will ultimately have a larger > impact on web2py's credibility than upgrading the documentation did. > But, doing it wrong will have immediate disastrous consequences.
