Software Versioning

I have been working on some tools for RSNA’s MIRC project. These tools offer different ways of creating radiology teaching files. MIRC lacks a developer API such as a web services API that would make integration easy and maintainable. Instead all integration is done via custom HTTP POSTs. For the non-developer that means that the application is programmed to fill out the forms just like you do. This is less than ideal since if the UI changes that developer may need to rewrite their code to talk to MIRC. This brings me to the saga of the last two days.

All of my authoring tools were completed and ready for testing. I tested it on my developer machine extensively and everything worked great. I distributed the tools to the testers and nothing worked for them. I sat at their machines and tried to make it work to no avail. We downloaded and reinstalled MIRC to make sure that they were using the same version that I was. The version that was listed on the web site was T30 gamma.

A quick word on software versioning. Whenever a developer pushes out a new version the version number needs to be incremented. So if my product’s version is 1.0.4, indicating that I have 4 maintenance releases after 1.0.0, when I make another change such as fix a bug the version will be 1.0.5. This is very important so that users know that this version is different than the previous version.

So I went home to my development machine to see what the problem was. I downloaded and reinstalled the version from the web site on my machine. Then it stopped working. Thinking that this was bizarre I worked on debugging for a while and did notice a couple of problems. They didn’t seem to make sense though. Finally I compared both the original MIRC installation file and the new one that I had downloaded. Would you believe that they are different? The code in the one that I originally downloaded was created on 11/4/2006 and the new one was 11/9/2006. Two different versions of the software marked with the same version. A cardinal sin in software development.

If projects like MIRC want to be taken seriously they need to employ proper software development methods. A developer cannot just push out a new version because he feels like it or he has fixed some bug and leave it as the same version. Most open source projects have many versions listed on their web site, including all minor releases for things such as bug fixes. What this issue with MIRC illustrates is a complete lack of any release controls and complete disregard for people who write software that inter operates with it.

Tags: , , , ,

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>