Pros/Cons of Turbogears/Rails?

Paul Boddie paul at boddie.org.uk
Thu Aug 31 12:04:53 EDT 2006


fuzzylollipop wrote:
> Paul Boddie wrote:
> > > fuzzylollipop wrote:
> > > > uh, no, Python predates Ruby by a good bit
> > > > Rails might be "older" than Turbogears but it still JUST went 1.0
> > > > officially.
> > > > It can't be called "mature' by any defintition.
> >
> > Version numbers are a fairly useless general metric of project
> > maturity, taken in isolation.
>
> But 1.0 releases do mean something, it means the DEVELOPER of the
> package things it is just now ready for general consumption. That means
> something regardless of what the number is.

In various open source circles, the mere usage of 1.0 may indicate some
kind of stability, but not necessarily maturity, or at least the desire
of the developers to persuade users that the code is ready for them to
use. Consequently, there are numerous stable packages at 0.x because
the developers don't think they're near finished (ie. have produced a
mature system), numerous unstable packages at 1.x because the
developers want their 15 minutes of fame (GNOME 1.0 was apparently a
good example of this), and various packages at 3.x or 4.x that would
suggest a legacy of decades when they've probably only been in
existence for eighteen months at the most.

> Matter of fact, all major version releaese mean that, it is generally
> understood thing. x.0 means this is now ready for non-beta general use.

Agreed. Still, let's take some examples from the python.org Wiki's
WebFrameworks page to illustrate what I mean:

SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3),
CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django
(0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid
(v0.7.0RC4), Paste (0.4.1), web.py (.138)

Now, just over half of the above have presumably passed some stability
threshold, and we could possibly even estimate the age of many of the
frameworks based on how high their version numbers are. However, note
that whilst Zope 3.2.1 is now presumably considered stable, something
like Zope 3.0 couldn't really be considered as mature as Zope 2.8 or
2.9 purely because of the nature of the code: a rewrite of the
architecture which, even if considered stable, cannot be considered
mature in comparison to its established predecessors with all the
accumulated expertise and experience associated with them.

Such comparisons of unequal things having the same name have also
affected projects like CherryPy, where 1.x and 2.x were apparently
quite different, and whilst CherryPy is currently at 2.2.1 and used by
other projects, it is described as unstable elsewhere in this thread -
contradicting various reports of successful large scale deployments, I
might add. Meanwhile, the original framework upstart, Webware, hasn't
even reached 1.0, yet it has been around for longer than many of the
others, whilst Pylons bears an identical version number.

Part of the difficulty in maintaining an overview such as the
WebFrameworks page arises from attempting to measure maturity,
stability, vitality and quality - something which some repositories
like Freshmeat attempt to tackle using various methods of measurement.
And as I was editing the version numbers recently, I did consider the
issue of whether they provided a reasonable impression of project
stability and/or maturity, but I rather feel that more considered
evaluations are the only way to get that kind of information.

Paul




More information about the Python-list mailing list