Two weeks seems like an eternity but we will have to do as you say.

Massimo

On May 17, 11:09 pm, "mr.freeze" <[email protected]> wrote:
> This is where web2py fails to earn its enterprise billing. Here's a
> simple solution: Call the released version the development version and
> promote the development version to the released version after 2-4
> weeks.
>
> On May 17, 10:38 pm, mdipierro <[email protected]> wrote:
>
> > You raise an excellent point.
>
> > So far the only security bug was the one reported a few months ago.
> > 1) Yet we do need a mechanism for reporting this kind of problems.
>
> > 2) We also need a team of volunteers committed to check nightly built
> > the week before release. So far very people check the nightly built.
>
> > 3) Definitively we need more tests about features in place to avoid
> > that new features break old features.
>
> > Bugs in new features are going to happen no matter what but that is
> > not a serious issue.
>
> > Massimo
>
> > On May 17, 10:00 pm, Kevin Bowling <[email protected]> wrote:
>
> > > I'm going to take a stab in the dark and venture to say that I'm not
> > > the only one using web2py in a "production" environment (i.e. people
> > > other than me are accessing the app) :-P
>
> > > It seems that with many recent releases there are rather embarrassing
> > > bugs.  The worst was several months ago when authentication was
> > > completely disabled.
>
> > > Can we adopt a strategy to minimize these potential disasters?  A
> > > sufficient beta channel would do the trick, and a tightening of what
> > > is acceptable as a release build.
>
> > > Also, how about a security channel so we know when an old version is
> > > unsafe and upgrades are mandatory?  Is there any statement on this
> > > already?
>
> > > Regards,
> > > Kevin

Reply via email to