A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've been a long time follower of the JoS forums, and today I finally have a question of my own.
I'm working on a private web service that gets consumed by about 15 customers. The version releases are generally breaking releases, so have to be tightly coordinated.
I plan to have three URLs. My private development URL, an interim development URL for my customers to bring the products up to current version and a production URL.
I plan on making critical fixes daily and non-critical fixes and new features monthly.
What is the best way to schedule these releases???
Function and fix freeze at end of month one, code thoses changes in month two, release day 1 of month three. So every month would be 1-Release last months changes, 2-Code this months changes, 3-Plan next months changes.
This sound about right?
Any ideas are appreciated.
Wednesday, July 25, 2007
I think you need to ask and answer some overall business questions in order to determine which release schedule is most appropriate.
For example, I can understand some services will insist on security and data integrity fixes made on a daily basis (as appropriate) but otherwise want to freeze the feature set for as long as a year or more. Obvious examples are the DNS servers and various timekeeping/clock synchronization systems.
Another issue I'd be concerned with is the penalties for failing to comply or upgrade within the one month period. Let's say I have an application that relies on your service. You introduce a new feature and break backwards compatibility. I have a month to update my system before the old one goes away (which by the way is a great idea). What happens if I can't afford to fix my application or my developer is on vacation and I don't make the transition in time?
For applications at the end of a dependency chain, i.e., public facing web sites that users directly interact with, this monthly maintenance schedule is in fact very common and many qa departments plan around monthly builds. But they're expecting to see a finished product or the sum of everything that went before.
On the other hand, people depend on web services being stable and consistent. I personally think a month is too fast, and in fact, I think feature upgrades to an existing service are a bad idea. I'd rather pick and choose from 10, 11, 12, 34, 800 different web services (all offered by you) than be forced to upgrade. It could be that version 1.0 provides me exactly with what I need, no more, no less, and I'd gain absolutely nothing from moving up to version 2.0.
Wednesday, July 25, 2007
Just incorporate the version number into the url and you're set. You can independently switch client versions without having to sync to anything - assuming the web service for that client version is deployed. This also assumes the url to the web service is somewhat backed into the client and the user doesn't have to browse to- or type in the url. If you also have version identifiers in your messages you can easily detect wrong versioned messages sent to a web service and return a meaningful error description.
Thursday, July 26, 2007
Great info so far!
I thought about the build number on the service name idea and that is awfully attractive. The part that would need to be worked out is breaking database changes on the back-end. I thought maybe the hassle would be worth it to put the build numbers on the stored proc names as well and just tolerate having a growing stored proc farm. I would still have NOT NULL issues.
As far as the scheduled method goes, after I get most of the features done, I could slow down the schedule to a quarterly(?) system. My web service provides a service that my customers offer as a feature to their customers. So you are right, I could hose a lot of people in a hurry.
I think the easiest method would be the scheduled method, but the most customer friendly would be the versioning method and drop support for builds every six months or so.
Please keep the comments flowing!
Thursday, July 26, 2007
I've been down this road myself. Definitely don't make your users upgrade monthly. I'd plan to support several public versions of your API simultaneously. Release major versions (breaking changes) yearly and non-breaking changes more regularly.
Think of the API (web services) as a facade. So long as the facade doesn't change, everything behind it can. As your core systems upgrade, use them to run the legacy APIs. This way, you don't need to worry about multiple sets of business logic trying to use the same resources (database).
The key to making this all work is having source-code control, a good branching strategy, and copious automated tests.
Monday, July 30, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz