So thats mean during 1.84.1 - 1.95.1 new features which will need a patch to web2py-core will be freezed and those wont need to touch web2py-core will be put into experimental?
On Sat, Aug 21, 2010 at 11:44 PM, mdipierro <[email protected]> wrote: > 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. >
