Websites Don't Release Anything
A couple weeks ago I was in London for a Launchpad team leads sprint. There were lots of cool discussions, focused mostly on processes within Launchpad. Because of all this process talk, we ended up talking about our release process a fair amount. I had some ideas forming before this, but a week's worth of discussion helped cement my thinking about "releases" for websites. Now some two weeks later, I'm still thinking about this, so here's a quick sketch of what's on my mind.
First, websites don't "release" anything. It's a metaphor, and a
poor one at that. We update the site with some version of our code.
Different sites do this differently. With regular updates to
edge (our beta site which many of
our users use anyway) Launchpad has many levels of release -- code
updates to edge regularly, db updates to staging regularly, and roll
outs of both to the main site monthly. Other sites just continually do the
equivalent of svn up on trunk on their site and apply DB
updates as needed.
Using the term "release" so casually also makes you feel like you have to build in artificial barriers to make the false release feel more like a traditional software release. Version numbers are a prime example of this. We give a version number to each month's "release" on Launchpad, and I think the only purpose this serves is to confuse developers and users about the meaning of the number. If I download Django 1.1 and hate it, I can choose to download Django 1.0 and use that instead. If you hate Launchpad 10.01, there's nothing you can do about it. If we bork something in 10.01, it's not like we're rolling back to December's release (whatever it was numbered). We will continue moving forward, adding a new branch that removes the busted feature or fixes the newly introduced bug, or what have you.
And it's this very act -- the act of continually moving forward -- that makes me hate talking about website releases all the more. What everyone who works on websites wants to do is move forward as quickly as possible, constantly adding new features and bug fixes to a site. The moment you place some arbitrary stopping point on the process and name it a release, you slow down forward progress.
I realize some would argue this a good thing, that stopping causes you to assess or do QA or ensure some other permanent quality is in the "release." But there's nothing permanent on the web. I would argue that rather than faking something permanent, your time would be better spent getting features and fixes to your users more quickly. I know I'm not alone in this, but still this word "release" hangs on, even in web development.
I'm excited, then, to see some of the changes we're proposing to our "release" process for Launchpad. Björn has proposed a way to release features when they are done which will require a new merge workflow for our work on Launchpad. These are all good things, even if the specifics may change as we discuss this among LP developers. The only thing that would make this better is to drop the word "release" from any discussions of these new proposals. But old habits die hard, as the saying goes.
Posted by deryck on February 16, 2010
Comments
Colin Dean on February 16, 2010 at 2:10 p.m.
This is the great thing about sites with APIs: folks can use whatever client they want for the site. Look at RSS, or, better yet, look at the vast number of Twitter clients, each filling their own niche and even becoming a sort of a business for some developers.
LP has a great API, and I've love to see folks take advantage of it. However, LP's site is so useful and well-designed that most folks don't have a desire to make a separate client.
deryck on February 16, 2010 at 4:14 p.m.
Hi, Colin.
We actually do have a lot of developers building stuff on top of the LP API. See the lpx project on Launchpad -- https://launchpad.net/lpx/.
Cheers,
deryck