Compound Thinking

TurboGears 1.0.5 released

On July first we cut out another 1.0.x TurboGears release.

I see this release as an ongoing effort to maintain our 1.0.x users and provide support and enhancements to existing applications.

While I am working with Mark and others on the 2.0 branch to make a release happen, I also work on the 1.5 front (formerly known as the 1.1 branch) to get this intermediary release out.

The 1.5 release aims to be 100% compatible with 1.0.x applications (running on python >= 2.4). I test regularly my development version against production applications that are running on top of TG 1.0 at the moment.

The real differences in 1.5 compared to 1.0 are:

• Different defaults for quickstarted projects, SQLAlchemy, Genshi instead of SQLObject and Kid.
• Testing Framework compatible with 2.0 to aid refactoring an application from 1.5 to 2.0 by using your test suit.
• RuleDispatch dropped from the required TurboJson version and replaced by PeakRules. Should not change too much for end users, but will help maintainers because we won’t need to precompile binaries.

At the end of the day I could say the TG scene is in a pretty good shape and we begin to see some attraction from the 2.0 branch, which is a good thing IMHO. And last but not least, releases always get more attention than simple SVN commits and we get users’ feedback in a much greater scale on such occasions, which is essential for an Open Source project such as ours.

TG2, and Release Management

TG2 has been a wild and crazy place with quite a few API changes over the last 4 months. Cutting a release makes installation easier, at least in a project like TurboGears 2, where dependency management is part of the release process.

It makes writing components easier–it’s easier to certify against a release than against a range of SVN checkouts.

On the other hand, releases seem to make promises about API stability, that we as developers aren’t always ready to make. I think that’s often a bad excuse for not doing the work needed to cut a release. After all we have limited time, and perhaps it is better if we spend that time working on “new stuff” rather than on packaging. The problem with that thinking is that releases provide a way for the development community to manage breaking API changes better, informing users about them in a central place, and providing users with tools to manage the pace of change.

So, releases are even more important when there’s lots of activity and potential API changes. . And they save time. Well, not my time personally, but every hour I spend doing releases makes getting started that much easier for hundreds, or thousands of people. Hopefully karma will result in some of those people contributing back.

Which is why we just cut a release, and why I think we should keep cutting releases on a regular basis from now to 2.0 final.

But how should we manage that process?

Open Source culture has a “we’ll release it when it’s done” philosophy which avoids all kinds of half baked stuff from getting released in a critically buggy state. And that’s a good thing.

On the other hand Ubuntu has taught us that it’s possible to have stable, complete, compelling software releases, in an open source world — and that it can be done on a predictable schedule.

So, I’m hopping that we can do time-based mini-releases of TG2 over the next few months, on our way to 2.0. I’m still thinking this through, but I think we will do a first alpha release this month, and follow that up with monthly releases until we hit 2.0.

2.0 final is very likely several months out, but having monthly releases between now and then will make that process easier, and can help us gather more testers, who are willing to put up with a bit of well managed API change on the way to 2.0.

Long term, I’m considering doing a 6 month time based release schedule, because it seems to have worked out well for Ubuntu.

And TG2 is a bit like Ubuntu or in that it brings together lots of little pieces to make something bigger, so may benefit from structuring our release process after theirs. But that’s just day-dreaming at this point, and I’m very interested in what other people think about how we can best manage the release process of TG.

At the same time, we probably should start thinking about version life-cycles and support timeliness. We’re planning on supporting 1.0 for at least the next a year after 2.0 final. But if there are people willing to help out I think that support could go on for longer (even forever, if enough people want it, that’s the beauty of open source!).

I’m not sure exactly how long is long enough… Heck, in general, what do you think? How should we manage releases and support-timelines in the TurboGears world. Is the Ubuntu system transferable to web-framework world?

We’re very serious about wanting to know what would make users most happy, so please let us know what you think.

TurboGears 2 gets a release

I’d like to officially announce the release of TurboGears 1.9.7 alpha 1. We’ve been working on this for a while yet, and while there’s still quite a bit of work to be done, we’ve now got a solid base to work from.

There’s a whole new section of the turbogears website devoted to TurboGears 2. We’re still working on TG2, and on the docs, as is expected with an alpha release, but I’m really excited about the new docs, which are generated using Sphinx.

Thanks to some help from the folks at the Repoze project, we’ve even got out own package index to use for installing TG2, so If you’ve already got setuptools installed, the install process is as easy as:


$ easy_install -i http://www.turbogears.org/2.0/downloads/1.9.7a1/index tg.devtools


Of course, we’ve got more detailed install instrutions including information on how to install into a clean virtual environment, so that you eliminate any possibility that you’ll get version conflicts in your main python install:

http://www.turbogears.org/2.0/docs/main/DownloadInstall.html

There are a lot of new features in TG2, an a lot more to come, so be aware that this is an alpha release, and we’ll probably see some API changes between now and 2.0 final. We’ll document those changes and tell you what you need to know to upgrade your project, but we’re not going to be afraid to improve and refine our API’s between now and the 2.0 final. So, if you’re not afraid of change, and are interested in helping to shape the next generation of dynamic web frameworks, hop on in and let us know what you think.

I think it’s worth reaffirming our commitment to the 1.x users. This does not mean we’re dropping support for TG1, if anything it looks like 1.x development is accelerating these days. So, if you’re interested in a stable, well tested, growing environment TurboGears 1 is still a great choice.

I’ll blog more this afternoon about my thoughts on the TurboGears 2 release schedule, and the release process. But, I’m very grateful to all of the people who helped out in order to make this release possible. Thanks a million times!

George Carlin on work

George Carlin’s passing this week was a suprising loss, not least because I always thought of someone who told hard truths in a way that made you laugh.

One of his famous quotes is:

Most people work just hard enough not to get fired and get paid just enough money not to quit.

In my experience this is true of too many software developers, and it’s a tragedy, particularly because when done well, software is about creative problem solving, which is the antithesis of “working just hard enough.”

“But, I’m Not Dead Yet”

I keep getting reports that TurboGears seems to be stagnant, and from the inside that just does not make sense: We’ve had 202 checkins in the the last 30 days. Which, by way of reference, is a tiny bit more than Django’s 183.

So, that seems to indicate that we’re definitely not quite dead yet. But, even that’s only half the story.

If you pull in checkins to a few components that are external to TG, but internal to Rails and Django (template language, ORM, forms + form validation, etc) that number grows significantly:

• 58 — SQLAlchemy — ORM
• 38 — Genshi — Template Language
• 113 — ToscaWidgets and tw.forms — Widgets, and Widget based Forms

Thats 353. Now if you pull in the changes to Pylons, related middleware and helpers, there’s another big jump:

• 56 — Pylons
• 106 — Paste
• 55— WebHelpers
• 36 — Routes
• 6 — Beaker

Now, of course there are other components which are actively contributing to the development of stuff that TurboGears users get as part of the package. But even ignoring all of that we’re looking at over 600 commits in the last month.

TurboGears ecosystem growth:

There’s also a growing ecosystem of turbogears stuff, and it’s all moving forward very quickly too.

Here’s a quick sample of projects I’m watching:

• 26 — TGTools
• 33 — tw.openlayers
• 31 — tw.dynforms
• 4— dbsprockets
• 7 — tw.dojo
• 16 — tw.jquery

There’s a new TG2 based CMS in the works too (http://code.google.com/p/lymon/). And there are a couple more very interesting projects that have not yet gone public.

Splitting our attention:

One thing that’s worth mentioning about all of this is that we’ve intentionally split our efforts over two areas:

1. Evolutionary improvements to TG 1.x
2. A new core in TG2.x

And that slows us down a bit. But it’s important because we want to take care of our installed userbase, and to try to grow into new areas at the same time. Doing one or the other would be way easier, but ignoring either one would be a huge mistake.

If it wasn’t for all the amazing stuff going on in the WSGi component world, TG2 would not be possible.

But because the wider python web community is developing new ways to work together around the WSGI model, tg2 development has been moving forward very well. And that’s one of the reasons why I’m so sold on the “component” model of framework development. Sure, it would be nice to have everything under one roof, and to have a stronger guiding hand on the whole process. But it’s not worth giving up all the innovation that happens “at the edges.”

TurboGears 1.x progress

On the evolutionary improvement front we’ve done lots to support SQLAlchemy, Genshi, ToscaWigets, DBSprockets, improve Json support, and created a brand new testing infrastructure, improved out authorization system, and otherwise made lots of positive changes. We’ve also had a half dozen new releases, with feature enhancements, averaging about a release a month.

TurboGears 2 progress

TG2 constitutes our revolutionary front, we’ve added many, many new features, and tools, and have maintained very significant API backwards compatibility, improved performance, and entirely redesigned the core of TurboGears. And we’re approaching our first alpha release in the next few days, so I don’t want to belabor the new stuff here.

What we need to do better:

I understand that not all of this work has been very visible, and that’s our fault, for not engaging the wider python community better, and it’s my fault in particular for not getting the TurboGears 2 work out into the wider world more quickly. Which is something I definitely intend to change in the very near future!

So, if you’re a part of the TG community, and you’re site/project needs to be better known, let me known, let me know. We need to raise the profile of some of the very interesting stuff that’s being done in the community, because outsiders seem to think that we’re not moving very fast, while insiders talk to me about the “blistering pace” of development.