subject:"\[web2py\] Re\: The stability of web2py releases"

On Dec 23, 2010, at 1:04 AM, cjrh wrote:
 
 On Dec 22, 6:05 pm, Thadeus Burgess thade...@thadeusb.com wrote:
 What I do is if my app works with a certain version, I don't ever upgrade
 the web2py unless I need a brand new feature or bugfix that effects me.
 
 +1.  If you don't need anything new, no point in upgrading.

The problem is that if you *do* need a bugfix, you ordinarily can't get it 
without adopting all the changes since the version you're currently using 
(unless you do your own patching).

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Branko Vukelić

On Thu, Dec 23, 2010 at 5:37 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Dec 23, 2010, at 1:04 AM, cjrh wrote:

 On Dec 22, 6:05 pm, Thadeus Burgess thade...@thadeusb.com wrote:
 What I do is if my app works with a certain version, I don't ever upgrade
 the web2py unless I need a brand new feature or bugfix that effects me.

 +1.  If you don't need anything new, no point in upgrading.

 The problem is that if you *do* need a bugfix, you ordinarily can't get it 
 without adopting all the changes since the version you're currently using 
 (unless you do your own patching).

That's another reason why you want to help test the 'release
candidate', right? :)

-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

On Dec 23, 2010, at 8:58 AM, Branko Vukelić wrote:
 
 On Thu, Dec 23, 2010 at 5:37 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Dec 23, 2010, at 1:04 AM, cjrh wrote:
 
 On Dec 22, 6:05 pm, Thadeus Burgess thade...@thadeusb.com wrote:
 What I do is if my app works with a certain version, I don't ever upgrade
 the web2py unless I need a brand new feature or bugfix that effects me.
 
 +1.  If you don't need anything new, no point in upgrading.
 
 The problem is that if you *do* need a bugfix, you ordinarily can't get it 
 without adopting all the changes since the version you're currently using 
 (unless you do your own patching).
 
 That's another reason why you want to help test the 'release
 candidate', right? :)

Seriously: no.

That is, if I'm using a release from six months ago, and all I need is a point 
fix, there's no reason for me to spend any time testing new release candidates. 
The bulk of web2py users, presumably, are not focused on web2py development; 
they're simply using web2py as a (very effective) tool to get their real work 
done. And there's nothing wrong with that.

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Branko Vukelić

On Thu, Dec 23, 2010 at 6:19 PM, Jonathan Lundell jlund...@pobox.com wrote:
 Seriously: no.

Seriously: yes. Why? Because it's YOUR work that is going to suffer if
you don't. Why WOULDN'T you test something you are going to deploy?
I've just tested dozen frameworks and even PHP before starting a
project, and I'm a hobbyist. Are you telling me professional
developers aren't expected to make an informed choice about their
platform? If that's the case, professional developers are people I
would NEVER trust to do their job right.

 That is, if I'm using a release from six months ago, and all I need is a 
 point fix,

Then you can dig around the commits and make yourself a patch. At
least that's what I'd do.


-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

On Dec 23, 2010, at 1:11 PM, Branko Vukelić wrote:
 
 On Thu, Dec 23, 2010 at 6:19 PM, Jonathan Lundell jlund...@pobox.com wrote:
 Seriously: no.
 
 Seriously: yes. Why? Because it's YOUR work that is going to suffer if
 you don't. Why WOULDN'T you test something you are going to deploy?
 I've just tested dozen frameworks and even PHP before starting a
 project, and I'm a hobbyist. Are you telling me professional
 developers aren't expected to make an informed choice about their
 platform? If that's the case, professional developers are people I
 would NEVER trust to do their job right.

Because I'm not deploying it (the current version, that is). 

For the same reason we don't tell users that they *must* use Python 2.7.1, and 
re-test their 2.4-based code for compatibility: it works.

Not me personally; I use the latest versions of stuff, pretty much. But I 
understand the reason for not wanting to, or at least not wanting to have to.

 
 That is, if I'm using a release from six months ago, and all I need is a 
 point fix,
 
 Then you can dig around the commits and make yourself a patch. At
 least that's what I'd do.

It's what I'd do too. But it makes web2py less friendly than it could be.

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Thadeus Burgess

Seriously: no.

I have way to many new features to add to the site and too little time to
worry about testing each time I upgrade.

--
Thadeus




On Thu, Dec 23, 2010 at 3:16 PM, Jonathan Lundell jlund...@pobox.comwrote:

 On Dec 23, 2010, at 1:11 PM, Branko Vukelić wrote:
 
  On Thu, Dec 23, 2010 at 6:19 PM, Jonathan Lundell jlund...@pobox.com
 wrote:
  Seriously: no.
 
  Seriously: yes. Why? Because it's YOUR work that is going to suffer if
  you don't. Why WOULDN'T you test something you are going to deploy?
  I've just tested dozen frameworks and even PHP before starting a
  project, and I'm a hobbyist. Are you telling me professional
  developers aren't expected to make an informed choice about their
  platform? If that's the case, professional developers are people I
  would NEVER trust to do their job right.

 Because I'm not deploying it (the current version, that is).

 For the same reason we don't tell users that they *must* use Python 2.7.1,
 and re-test their 2.4-based code for compatibility: it works.

 Not me personally; I use the latest versions of stuff, pretty much. But I
 understand the reason for not wanting to, or at least not wanting to have
 to.

 
  That is, if I'm using a release from six months ago, and all I need is a
 point fix,
 
  Then you can dig around the commits and make yourself a patch. At
  least that's what I'd do.

 It's what I'd do too. But it makes web2py less friendly than it could be.

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread pbreit

I think it's definitely a worthwhile goal to evolve the release schedule 
into stable and feature branches with bugs getting back-ported but suspect 
it will take some time to get there.

Part of the value of a framework is being able to count on its stability. 
For now, we can upgrade more slowly and pay attention to stability reports 
of new releases.

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Branko Vukelić

On Thu, Dec 23, 2010 at 10:40 PM, pbreit pbreitenb...@gmail.com wrote:
 Part of the value of a framework is being able to count on its stability.
 For now, we can upgrade more slowly and pay attention to stability reports
 of new releases.

Yes, yes. Sit around and wait. For what reports again? Based on what
bug reports again? Everyone was sitting and waiting for Massimo to
actually label it as stable release. How wonderful. I'm sure that's
the BEST strategy to ensure web2py is bug free in future releases. Oh,
and what happens if Massimo's stable release turns out to be not that
stable after all? Well, this thread happens.

Last I've heard, Massimo was a single person. I don't know if he can
multiply like amoebae, but I'm sure it'd help if we all just dug into
release candidates or even trunk and _at least_ poked around. Even
better, why not deploy your latest awesome project on the new release
and give it a spin?

All in all, some of you guys are just... I dunno. Irrational. (Or
retarded, but I hope not.) You take far too many things for granted.
FAR too many things. And you fight any notion that doesn't match that
vision. So you don't see the beauty of free software, fine. But what's
this?! Even free as in beer isn't enough for you! You want it ALL. And
what IS the 'all'? Even you don't know. I'll tell you what you want.
You want open-source projects to submit to YOUR selfish and
self-centered vision. Instead of talking about contribution (of your
valuable time to the project that SAVES your valuable time), you
demand, and demand, and demand.

You keep babbling about your selfish needs, not even considering that
there are actual people who have THEIR OWN needs and yet make time to
listen to you, and implement shit in record time. And again, it has to
be said, that saves you your valuable time. Is that not enough for
you? Doesn't that make you happy? Is that ENOUGH?

Well, you know what. You should all be ashamed. You have absolutely NO
RIGHT to demand anything from Massimo or any other contributor. And
don't tell me about how you love web2py but you just wanted X or Y.
You OWE web2py X and Y, so if you want it, just do it yourself. YOU
label releases as stable, and YOU implement stuff. If Massimo does
that for you, it's a BIG FAT favor, and you should keep that in mind.

-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

On Dec 23, 2010, at 2:17 PM, Branko Vukelić wrote:
 
 You keep babbling about your selfish needs, not even considering that
 there are actual people who have THEIR OWN needs and yet make time to
 listen to you, and implement shit in record time. And again, it has to
 be said, that saves you your valuable time. Is that not enough for
 you? Doesn't that make you happy? Is that ENOUGH?

I suspect that we're talking at cross purposes.

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Thadeus Burgess

Kinda of joking, but also kinda serious. It cost time and money to have to
test something just because a decision was made to upgrade the library (in
this case, web2py).

--
Thadeus




2010/12/23 Branko Vukelić stu...@brankovukelic.com

 On Thu, Dec 23, 2010 at 10:29 PM, Thadeus Burgess thade...@thadeusb.com
 wrote:
  Seriously: no.
 
  I have way to many new features to add to the site and too little time to
  worry about testing each time I upgrade.

 I really hope you're just joking, and I'm just too stupid to get the
 funny part. :P

 --
 Branko Vukelic

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Thadeus Burgess

Good. Now this thread can go into the list of many archived threads about
this topic.

Nothing will happen and things will continue as they have been, which isn't
so bad because nobody is forcing you to upgrade your web2py version each
time a new release comes out.

However, Branko, part of the problem that nobody else can even perform basic
release management. Nobody but Massimo has access to trunk, and therefore
nobody but Massimo can make releases, create branches, maintain stable etc.
This leaves the project in a odd state that the only thing that can be done
is to complain.

Its free software, if you don't like it, fork it and manage it yourself.

--
Thadeus




2010/12/23 Branko Vukelić stu...@brankovukelic.com

 On Thu, Dec 23, 2010 at 11:21 PM, Jonathan Lundell jlund...@pobox.com
 wrote:
  I suspect that we're talking at cross purposes.

 I have nothing more to say in this ridiculous thread.

 --
 Branko Vukelic

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

[web2py] Re: The stability of web2py releases

2010-12-23 Thread weheh

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.

[web2py] Re: The stability of web2py releases

2010-12-23 Thread mdipierro

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 mN 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 richard_gor...@verizon.net 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.

[web2py] Re: The stability of web2py releases

2010-12-23 Thread ron_m

I for one am happy with the current release cycle. It is a good balance 
between new features and the ultimate stability of release 1.XX.N  where N 
is the last version before XX+1 for example. The nightly build is a bit of a 
misnomer, many projects (C or C++ mostly) have some automated process that 
takes trunk and compiles it to produce a .tar.gz labelled nightly which 
might work. For web2py we should just hg pull; hg update to achieve that 
result. The nightly for web2py is more like a beta because Massimo hand 
picks code from trunk that will or will not be in the nightly which could 
really be a weekly.

I am currently developing the application I am working on and testing is 
easy enough that I test trunk at least daily. The web2py server is quite 
easy to use but the code in some places is complicated and has many possible 
use cases. It is only through exposure out to the user base that a large 
number of use cases of the code get tested. I have even seen problems 
reported where something was fixed but used by maybe one person in a way 
that should not have worked resulting in the dreaded bug that worked and 
became a useful feature for someone.

Once I go to production I will probably move the releases a lot slower 
through the installed base. In fact I have 2 beta production systems up now 
and only push a new web2py when I push a new version of the application to 
the stakeholders to look at.

Massimo provides a fantastic service with the web2py project and I would not 
like to see him stifled by a load of process. Anyone that has time to test 
will definitely help the quality, if you don't have time, that is okay too. 
I personally don't mind doing some release management between where Massimo 
is burning the midnight oil and what I let out into the production systems I 
have/will manage. The product is alive with new features and bug fixes 
sometimes occur in minutes once reported. That is worth a lot.

Ron

Re: [web2py] Re: The stability of web2py releases

2010-12-23 Thread Luis Díaz

2010/12/24 ron_m ron.mco...@gmail.com

I for one am happy with the current release cycle. It is a good balance
between new features and the ultimate stability of release 1.XX.N where N
is the last version before XX+1 for example. The nightly build is a bit of a
misnomer, many projects (C or C++ mostly) have some automated process that
takes trunk and compiles it to produce a .tar.gz labelled nightly which
might work. For web2py we should just hg pull; hg update to achieve that
result. The nightly for web2py is more like a beta because Massimo hand
picks code from trunk that will or will not be in the nightly which could
really be a weekly.

I am currently developing the application I am working on and testing is
easy enough that I test trunk at least daily. The web2py server is quite
easy to use but the code in some places is complicated and has many possible
use cases. It is only through exposure out to the user base that a large
number of use cases of the code get tested. I have even seen problems
reported where something was fixed but used by maybe one person in a way
that should not have worked resulting in the dreaded bug that worked and
became a useful feature for someone.

Once I go to production I will probably move the releases a lot slower
through the installed base. In fact I have 2 beta production systems up now
and only push a new web2py when I push a new version of the application to
the stakeholders to look at.

Massimo provides a fantastic service with the web2py project and I would
not like to see him stifled by a load of process. Anyone that has time to
test will definitely help the quality, if you don't have time, that is okay
too. I personally don't mind doing some release management between where
Massimo is burning the midnight oil and what I let out into the production
systems I have/will manage. The product is alive with new features and bug
fixes sometimes occur in minutes once reported. That is worth a lot.

Ron

--
Díaz Luis
TSU Analisis de Sistemas
Universidad de Carabobo

http://web2pyfacil.blogspot.com/
Facultad de
Odontologíahttp://www.odontologia.uc.edu.ve/index.php?option=com_contentview=articleid=102Itemid=85

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Michele Comitini

should we have a stable and beta (latest) release?  Many people do not
use trunk, because changes too fast I guess.
Having a beta period before stable could help attract more beta
testers, but I think it would add a burden for version control...

mic


2010/12/22 ron_m ron.mco...@gmail.com:
 If you are sensitive to new releases to production then take a slower
 approach. 1.90.1 to 1.90.6 happened in just over a day with very big changes
 coming into 1.90.1 to make the future development in certain directions
 possible. I think there were more problems found in trunk testing before
 release than after. I helped test trunk but once everything was fixed for my
 use of the application server I could no longer add any value since it all
 worked for me for at least a week before the public release came out. If
 production was on 1.89.5 and a one week wait were used post next release
 which I would consider aggressive upgrading to production then 1.91.1 would
 be where you are today which is mostly license comments compared to 1.90.6.

 I am still developing the application I am working on so I follow the
 releases quickly there to get some testing in but I have some beta
 production systems up and haven't touched them in several weeks. I guess
 they call that staging. I also hang onto a copy of the old release until I
 am sure the next is good so it can be swapped back quickly.

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 9:17 AM, Michele Comitini
michele.comit...@gmail.com wrote:
 should we have a stable and beta (latest) release?  Many people do not
 use trunk, because changes too fast I guess.
 Having a beta period before stable could help attract more beta
 testers, but I think it would add a burden for version control...

Why not just label new releases as edge or something, and leave a
copy of an old release labeled stable? That way, release model is
unchanged, but people do get some idea about the expected stability.


-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

[web2py] Re: The stability of web2py releases

2010-12-22 Thread KR

I support that.
For me the last stable is 1.89.5 (or maybe 1.90.6 ? if the new DAL is
stable)
The only missing stuff is a place to download it.

On 22 déc, 15:49, Branko Vukelić stu...@brankovukelic.com wrote:
 On Wed, Dec 22, 2010 at 3:44 PM, appydev appy...@gmail.com wrote:
  I think there should be a version, not to call it ... ,
  Something likeUbuntu LTS (Long Term Support). and that
  this version receiveimmediate bug fixes. and other critical updates that do
  notprovide new features mean, for a considerable time until thestable
  version and has been sufficiently tested.

 LTS is a completely different ting. It means a lot of backporting of
 stuff that's fixed in later releases, and keeping it supported for 3
 years. I don't think any framework does it. It's sufficient that we
 have a stable and unstable (or edge, or whatever) versions. The latter
 would be a _released_ version, but is not considered thoroughly
 tested. It's like Debian's unstable-testing-stable cycle.

 --
 Branko Vukelic

 stu...@brankovukelic.comhttp://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Luis Díaz

in particular whenever new versions come out ... I always say ... have to wait
1 week or 2 to becomestable ...

unless the new features are highly anticipated and then one is
dedicated to testing
the system

2010/12/22 KR kaerbu...@gmail.com

I support that.
For me the last stable is 1.89.5 (or maybe 1.90.6 ? if the new DAL is
stable)
The only missing stuff is a place to download it.

On 22 déc, 15:49, Branko Vukelić stu...@brankovukelic.com wrote:
On Wed, Dec 22, 2010 at 3:44 PM, appydev appy...@gmail.com wrote:
I think there should be a version, not to call it ... ,
Something likeUbuntu LTS (Long Term Support). and that
this version receiveimmediate bug fixes. and other critical
updates that do
notprovide new features mean, for a considerable time until thestable
version and has been sufficiently tested.

LTS is a completely different ting. It means a lot of backporting of
stuff that's fixed in later releases, and keeping it supported for 3
years. I don't think any framework does it. It's sufficient that we
have a stable and unstable (or edge, or whatever) versions. The latter
would be a _released_ version, but is not considered thoroughly
tested. It's like Debian's unstable-testing-stable cycle.

--
Branko Vukelic

stu...@brankovukelic.comhttp://www.brankovukelic.com/

--
Díaz Luis
TSU Analisis de Sistemas
Universidad de Carabobo

http://web2pyfacil.blogspot.com/
Facultad de
Odontologíahttp://www.odontologia.uc.edu.ve/index.php?option=com_contentview=articleid=102Itemid=85

Re: [web2py] Re: The stability of web2py releases

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.


-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Thadeus Burgess

Funny,

Every three to four weeks this topic of discussion comes up.

Lots of the same ideas are said over and over again.

Nobody has time to work on certain things like this since most of us have
full time jobs that may or may not be related to web2py.

What I do is if my app works with a certain version, I don't ever upgrade
the web2py unless I need a brand new feature or bugfix that effects me. This
has been my adaptation to the fast development cycle.

Think of web2py as the gentoo of python web frameworks... its *very* fast
and efficient and you get lots of new stuff often, but expect updates to
break.

--
Thadeus




2010/12/22 Branko Vukelić stu...@brankovukelic.com

 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.


 --
 Branko Vukelic

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 5:05 PM, Thadeus Burgess thade...@thadeusb.com wrote:
 Nobody has time to work on certain things like this since most of us have
 full time jobs that may or may not be related to web2py.

What do you mean? No time to develop a system of labeling releases or
no time to upgrade, test, etc?

-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Thadeus Burgess

The latter.

No time to test aside from upgrading in production.

No time to develop a test application which can handle all of web2py
features (including all DAL databases)

No time to set up and maintain a server just for said tests.

--
Thadeus




2010/12/22 Branko Vukelić stu...@brankovukelic.com

 On Wed, Dec 22, 2010 at 5:05 PM, Thadeus Burgess thade...@thadeusb.com
 wrote:
  Nobody has time to work on certain things like this since most of us have
  full time jobs that may or may not be related to web2py.

 What do you mean? No time to develop a system of labeling releases or
 no time to upgrade, test, etc?

 --
 Branko Vukelic

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

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.

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread pbreit

I do think at some point the concept of stable and new will be useful 
for newer users. stable might be a loaded word so maybe just recommended 
or something. One challenge will be how to process bug fixes on stable. A 
start may be the ability to specify a branch in admin. And new users could 
be encouraged to use the previous branch (ie, 1.90.6 vs 1.91.3).

Re: [web2py] Re: The stability of web2py releases

On Dec 22, 2010, at 9:17 AM, pbreit wrote:
 I do think at some point the concept of stable and new will be useful for 
 newer users. stable might be a loaded word so maybe just recommended or 
 something. One challenge will be how to process bug fixes on stable. A 
 start may be the ability to specify a branch in admin. And new users could be 
 encouraged to use the previous branch (ie, 1.90.6 vs 1.91.3).

This would be a better solution if we actually had stable branches, with 
back-ported bug fixes. As it is, bug fixes are inseparable from new features, 
unless individual users are prepared to do their own patching. Which happens, 
of course, as we saw today with dcrodjer's GAE folder-creation problem, but 
isn't that useful for most users.

Formal support for stable branches would be a good indication of web2py's 
growing maturity, but somebody's got to commit the time.

(This kind of discussion also tends to go off in the regression-test 
direction)

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 5:57 PM, Thadeus Burgess thade...@thadeusb.com wrote:
 The latter.

 No time to test aside from upgrading in production.

Oh, but that's a bit upside down. web2py comes with no warranties, you
should at least test it a bit before going live. And as a double-win,
you also help judging the quality of web2py release. Just updating the
live site would be plain irresponsible, I think, even if Massimo had a
clean bug-free record. Of course, you can do it anyway if it's not a
mission-critical site (not too many users, or very forgiving users,
etc), but for an important site, it's just not a good practice in
general, regardless of web2py's release scheme.

 No time to develop a test application which can handle all of web2py
 features (including all DAL databases)

That's why I suggested the unstable-stable scheme in the first place.
Test unstable. If it's good for you, shoot a message to mailing list
(if you want), and deploy it. If it's not good, then shoot a bug
report to the mailing list, and Massimo can roll out the bugfix
release soon after that. Rinse, repeat.

 No time to set up and maintain a server just for said tests.

See above about the said tests. On the other hand, I don't think it
would be too crazy to make a test server (or even a test virtual host)
just for testing the potential candidate for live deployment.

-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Bruno Rocha

I see the need to organize a test team

Some ideas:
https://wiki.ubuntu.com/Testing
https://wiki.ubuntu.com/Testinghttps://wiki.ubuntu.com/Testing/LoCoTeam
http://ubuntutesting.wordpress.com/2010/08/06/desktop-testing-team/
https://launchpad.net/~desktop-testing-team

Or, we can organizze Local Sprints for testing new major releases. (jus like
python does)

-- 

Bruno Rocha
http://about.me/rochacbruno/bio

[web2py] Re: The stability of web2py releases

2010-12-22 Thread mdipierro

The idea was to have stable and nightly-build. The problem is that
very few people check the nightly build.

On Dec 22, 11:17 am, pbreit pbreitenb...@gmail.com wrote:
 I do think at some point the concept of stable and new will be useful
 for newer users. stable might be a loaded word so maybe just recommended
 or something. One challenge will be how to process bug fixes on stable. A
 start may be the ability to specify a branch in admin. And new users could
 be encouraged to use the previous branch (ie, 1.90.6 vs 1.91.3).

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 8:29 PM, mdipierro mdipie...@cs.depaul.edu wrote:
 The idea was to have stable and nightly-build. The problem is that
 very few people check the nightly build.

Well, yeah, it's because it's sounds like a nightly TRUNK dump. :)
It's better to make a 'incubation release' or something like that, so
it's obvious that it's a release. And when it's hatched, you can label
it safe-for-production. I don't know if people would use them, though.
They might still go yuck and decide it's just like nightly, with a
fancy name. :D


-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Vasile Ermicioi

that means we prefer a stable one :)

[web2py] Re: The stability of web2py releases

2010-12-22 Thread mdipierro

We can change the name. It is not truly a nigthly built. it is closer
to a release candidate even if the final release is not equivalent to
the latest nightly built.

On Dec 22, 1:31 pm, Branko Vukelić stu...@brankovukelic.com wrote:
 On Wed, Dec 22, 2010 at 8:29 PM, mdipierro mdipie...@cs.depaul.edu wrote:
  The idea was to have stable and nightly-build. The problem is that
  very few people check the nightly build.

 Well, yeah, it's because it's sounds like a nightly TRUNK dump. :)
 It's better to make a 'incubation release' or something like that, so
 it's obvious that it's a release. And when it's hatched, you can label
 it safe-for-production. I don't know if people would use them, though.
 They might still go yuck and decide it's just like nightly, with a
 fancy name. :D

 --
 Branko Vukelic

 stu...@brankovukelic.comhttp://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Anthony

Also, you probably need some kind of announcement to prompt testing -- 
there's nothing prompting people to check the nightly build (or even to know 
when anything substantial has been added to it). When a new .1 release 
(e.g., 1.91.1) is announced (usually with a list of new features), that 
prompts people to check it out. Maybe instead of starting with .1, start 
with a release candidate (e.g., 1.92.0rc or something), then spend a few 
days debugging before releasing a more stable .1 (so what we currently call 
.1 would become the RC, and what currently ends up being .3 or .4 would be 
.1). Essentially the same behavior as now, just slightly different labeling. 
That's not to say we couldn't use other improvements to the process (e.g., 
more systematic testing), but this might be a simple change.
 
Anthony

On Wednesday, December 22, 2010 2:31:45 PM UTC-5, stu...@brankovukelic.com 
wrote:

 On Wed, Dec 22, 2010 at 8:29 PM, mdipierro mdip...@cs.depaul.edu wrote:
  The idea was to have stable and nightly-build. The problem is that
  very few people check the nightly build. 

 Well, yeah, it's because it's sounds like a nightly TRUNK dump. :)
 It's better to make a 'incubation release' or something like that, so
 it's obvious that it's a release. And when it's hatched, you can label
 it safe-for-production. I don't know if people would use them, though.
 They might still go yuck and decide it's just like nightly, with a
 fancy name. :D 


 -- 
 Branko Vukelic 

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Anthony

Oh, also, I noticed a typo on the website -- it says Nightly Built instead 
of Nightly Build. Maybe that's the problem. ;-)

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 8:47 PM, Anthony abasta...@gmail.com wrote:
 Oh, also, I noticed a typo on the website -- it says Nightly Built instead
 of Nightly Build. Maybe that's the problem. ;-)

Is there a typo on this planet that can evade Anthony? :D


-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Anthony

Please, don't encourage me. :D

On Wednesday, December 22, 2010 3:13:32 PM UTC-5, stu...@brankovukelic.com 
wrote:

 On Wed, Dec 22, 2010 at 8:47 PM, Anthony abas...@gmail.com wrote:
  Oh, also, I noticed a typo on the website -- it says Nightly Built 
 instead
  of Nightly Build. Maybe that's the problem. ;-) 

 Is there a typo on this planet that can evade Anthony? :D 


 -- 
 Branko Vukelic 

 stu...@brankovukelic.com
 http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

On Dec 22, 2010, at 11:42 AM, mdipierro wrote:
 
 We can change the name. It is not truly a nigthly built. it is closer
 to a release candidate even if the final release is not equivalent to
 the latest nightly built.

I'm sounding like a broken record here (remember those?), but in view of the 
rapid pace of web2py feature development, I don't think we can really achieve 
stability without separate, stable branches that allow *only* low-risk, 
reviewed bug fixes.

And that doesn't come for free; it requires time (and discipline).

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Michele Comitini

Web2py supports unit testing.  Why not have an app with controller(s)
that can be tested for each solved bug?
 this would reduce at least regressions.  Kinda continuos integration system

2010/12/22 Jonathan Lundell jlund...@pobox.com:
 On Dec 22, 2010, at 11:42 AM, mdipierro wrote:

 We can change the name. It is not truly a nigthly built. it is closer
 to a release candidate even if the final release is not equivalent to
 the latest nightly built.

 I'm sounding like a broken record here (remember those?), but in view of the 
 rapid pace of web2py feature development, I don't think we can really achieve 
 stability without separate, stable branches that allow *only* low-risk, 
 reviewed bug fixes.

 And that doesn't come for free; it requires time (and discipline).

Re: [web2py] Re: The stability of web2py releases

On Wed, Dec 22, 2010 at 9:38 PM, Michele Comitini
michele.comit...@gmail.com wrote:
 Web2py supports unit testing.  Why not have an app with controller(s)
 that can be tested for each solved bug?
  this would reduce at least regressions.  Kinda continuos integration system

That also requires time and discipline, if I'm not mistaken. :)

The current way of testing (open-compaint system) is totally cool.
What I mean is, it works. People get stuck, they complain, Massimo
fixes. It's about how to get people to test-deploy apps with unstable
releases instead of going WTF?! when deploying a new release. I
think that would be less time-consuming, and less frustrating for end
users as well.



-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

[web2py] Re: The stability of web2py releases

2010-12-22 Thread Stefaan Himpe




Is there a typo on this planet that can evade Anthony? :D


While we're on the subject... *cough*experts4solutions.com*cough*
Its typos still make my eyes bleed :p

[web2py] Re: The stability of web2py releases

2010-12-22 Thread Michael McGinnis

I'd like to help fix those typos. Let me know how I can get started.

Michael McGinnis
michael.d.mcgin...@gmail.com

On Dec 22, 4:01 pm, Stefaan Himpe stefaan.hi...@gmail.com wrote:
  Is there a typo on this planet that can evade Anthony? :D

 While we're on the subject... *cough*experts4solutions.com*cough*
 Its typos still make my eyes bleed :p

Re: [web2py] Re: The stability of web2py releases

Shoot Massimo an e-mail. I'm sure he'd be happy to hear from you.

On Wed, Dec 22, 2010 at 11:37 PM, Michael McGinnis
ish...@biographiks.com wrote:
 I'd like to help fix those typos. Let me know how I can get started.

 Michael McGinnis
 michael.d.mcgin...@gmail.com

 On Dec 22, 4:01 pm, Stefaan Himpe stefaan.hi...@gmail.com wrote:
  Is there a typo on this planet that can evade Anthony? :D

 While we're on the subject... *cough*experts4solutions.com*cough*
 Its typos still make my eyes bleed :p




-- 
Branko Vukelic

stu...@brankovukelic.com
http://www.brankovukelic.com/

Re: [web2py] Re: The stability of web2py releases

2010-12-22 Thread Plumo

agreed. Less overhead to releases means new features get added faster.

[web2py] Re: The stability of web2py releases

2010-12-22 Thread VP

In my humble opinion, the word Enterprise demands a more systematic
approach to dealing with this issue.  I think the simplest way is
perhaps has a numbering scheme that is understood by everyone.  For
example, increment the third number (e.g. from 1.90.2 to 1.90.3) only
for bug fixes, and increment the second number (e.g. from 1.90.3 to
1.91.0) for major releases or addition of new features.

[web2py] Re: The stability of web2py releases

2010-12-22 Thread Luther Goh Lu Feng

I think the suggested versioning works great

What I suggest is perhaps label the latest release as the testing
branch eg 1.91 is the testing branch. 1.90 will be the stable branch.
These will of course increment by 0.01 in the next web2py release.

In the admin panel, have the option for the user to upgrade/downgrade
to/from the testing/stable branches.

On Dec 23, 11:07 am, VP vtp2...@gmail.com wrote:
 In my humble opinion, the word Enterprise demands a more systematic
 approach to dealing with this issue.  I think the simplest way is
 perhaps has a numbering scheme that is understood by everyone.  For
 example, increment the third number (e.g. from 1.90.2 to 1.90.3) only
 for bug fixes, and increment the second number (e.g. from 1.90.3 to
 1.91.0) for major releases or addition of new features.

[web2py] Re: The stability of web2py releases

2010-12-22 Thread Luther Goh Lu Feng

To clarify, what I am saying is, no change to current release system,
except to label stable and testing branches. It's a little like the
branches of Debian Linux 
http://wiki.linuxquestions.org/wiki/Debian#Stable.2C_Testing.2C_Unstable.2C_and_Experimental

web2py probably don't need so many branches.

On Dec 23, 11:52 am, Luther Goh Lu Feng elf...@yahoo.com wrote:
 I think the suggested versioning works great

 What I suggest is perhaps label the latest release as the testing
 branch eg 1.91 is the testing branch. 1.90 will be the stable branch.
 These will of course increment by 0.01 in the next web2py release.

 In the admin panel, have the option for the user to upgrade/downgrade
 to/from the testing/stable branches.

 On Dec 23, 11:07 am, VP vtp2...@gmail.com wrote:







  In my humble opinion, the word Enterprise demands a more systematic
  approach to dealing with this issue.  I think the simplest way is
  perhaps has a numbering scheme that is understood by everyone.  For
  example, increment the third number (e.g. from 1.90.2 to 1.90.3) only
  for bug fixes, and increment the second number (e.g. from 1.90.3 to
  1.91.0) for major releases or addition of new features.

Re: [web2py] Re: The stability of web2py releases