Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Why web services versioning is important

Freshness Warning
This blog post is over 18 years old. It's possible that the information you read below isn't current and the links no longer work.

Two words: client synchronization.

Talking to Bill Lazar, he suggested that my web serrvices versioning problems are similar to his problems with Ruby on Rails. He’s got some code running on a pre-1.0 RoR installation. With 1.0, several important constructs changed in the framework, and upgrading to 1.0 would break his application. As we chatted through this, we hit upon the key difference. Although RoR released 1.0, there’s nothing forcing him to actually use it. He can keep using 0.9 (or whatever version he has) as long as he wants. He can try his code on a 1.0 system elsewhere, test it, adjust it, and prepare it for use. Then when he’s ready, he can upgrade his code and his RoR installation at the same time. The version negotiation between the client and server can be planned and synchronized.

For a data structure or service delivered over the public web to a disparate set of clients, this isn’t possible. I cannont time the upgrade of the server to co-incide with an upgrade of the client. In many cases, I don’t even know who the client is. I certainly don’t control them. And even if I knew them all, synchronizing an upgrade would require that I coordinate the upgrade schedules of multiple clients, maintained by multiple people, with varying degrees of interest and need.

The essential component in Bill’s Rails upgrade is a time shift. The RoR framework was released, but Bill can choose when it applies to him by shifting the upgrade to a time that suits him. People that need it now, or are just starting out with Rails can get the 1.0 version immedately. Everyone else can use whatever version they want. The Rails team doesn’t need to maintain old versions of the application. It’s acceptable to say that bugs in the app are fixed in the later versions only and if you have a problem that needs fixing, you should accelerate your upgrade schedule.

With a web service, I can time shift the upgrade path by continuing to supply older versions of the data format. There’s no maintenance involved. The format sits there, and anyone connecting to it can use it. If someone has a problem or needs some new data, they can get it by moving to the newest version. Any new uses of the service start out with the latest version.

Recently Written

A Framework for Scaling product teams (Oct 9)
The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
Video calls using a networked camera (Sep 25)
A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features (Sep 4)
Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks (Sep 2)
The key to effective roadmapping? Different views for different needs.
Micromanaging and competence (Jul 2)
Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system (Jun 24)
A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. But failing is an important part of innovation. If you can't let it fail, it can't succeed.

Older...

What I'm Reading