Compound Thinking

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.