How about we start testing with 1.84.1... and release 1.95.1 and the end of the testing period?
On Aug 21, 12:00 pm, Phyo Arkar <[email protected]> wrote: > > I think so, as long as the terms are clear. In particular, it should be > > clear how the experimental features would move to stable (perhaps just a > > time limit on the stress test, or some more specific condition). > > how about this? > Lets say , during 4 weeks of bug-squishing period , all expermental > features will be also tested for bugs , if they exist they will be report to > the contributor of that feature , if the contributor or anyone send the > patch(and if contributor statify the patch if some other fixed) , that > feature will be included in main-stream , else they will tagged exprimental. > > how about that sounds? > > it should be exercised at every Stability level versions. lets say every > x.x5 (1.85 for example but any number that massimo wish) . As web2py is > aimed for Enterprise level , this should make development look and feel > "Enterprise". > > On Sat, Aug 21, 2010 at 9:15 PM, Jonathan Lundell <[email protected]>wrote: > > > On Aug 20, 2010, at 2:40 PM, mdipierro wrote: > > > > I see a lot of value in > > > > - bug-squishing-contest , > > > - Stress test, Test everything , try to crash web2py etc. > > > - fix bugs, fix performance issues , improve performance > > > - code cleanup , documentation. > > > > we can set deadlines for that. This means we would stress test and > > > improve features existing at a certain date and we would only add new > > > features tagged as "experimental" that do not interfere with parts > > > that are being stress tested. Makes sense? > > > I think so, as long as the terms are clear. In particular, it should be > > clear how the experimental features would move to stable (perhaps just a > > time limit on the stress test, or some more specific condition). > > > Perhaps in going through an exercise like this, we could also think about > > something like it could be incorporated into the normal development cycle, > > on an ongoing basis rather than as a one-shot project.
