So I’m reading about release management these days. Thanks to those who reccommended Karl Fogel’s open source book, particularly this chapter 7.
So while mulling over all this stuff, I get this announcement about Metalib. (A not at all atypical one, I’ve seen this exact announcement with different version numbers in it before)
We have addressed this problem with an additional fix – number 403 – and have re-packaged the 4.2.2 SP. Detailed instructions follow both for customers who have or have not already applied the previous package to their MetaLib installations.
If you have previously applied the MetaLib 4.2.2 package, please re-apply the new [4.2.2] package. Only the new fix will be loaded to your MetaLib installation.
Yes, what that means is, if you applied the 4.2.2 update yesterday, you have different software than if you’ve applied the 4.2.2 update today.
This is insanity! The only way to know what software you really have is to keep track in external notes. And you never know when they’re going to do this in teh future, so you better keep really good notes on exactly what you apply when. So if four months from now, they say, oh, but which x.x.x do you have, did you (re-)apply it after or before we fixed it? INSANITY. Busy (or cautious) admins do not always apply the updates exactly when they are released. Sometimes I go months without applying a released update. Maybe that’s bad, but that’s how it goes sometime. I need to be able to examine my software and see what version it is, and what I need to do to update it, and have this information be clear and reliable. There can’t be two different versions both called 4.2.2.
This goes against the whole point of giving things version numbers in the fisrt place. You can’t erase history and pretend you never made the mistake, magic, 4.2.2 is different now! It is ridiculous. I’m fed up with it!
Okay, I’ll stop ranting now.
I can only guess that this saves time on Ex Libris’s end. If they were going to release a 4.2.3 (or a 220.127.116.11), maybe they’d have to follow some internal QA procedures (I am generously assuming they have such, although they really need some improvement, clearly, since this exact scenario happens with a large number of update releases). They’d have to actually build the new package. Maybe their package management system can’t handle a fourth unit (18.104.22.168), and they’ve already got internal road-maps that say 4.2.3 is going to be six months from now and something else. I don’t know, who knows.
But it’s really not acceptable from the customer’s point of view. I’m really sick of our vendor’s ignoring what are universally accepted best practices in the rest of the software world. Like, um, you can’t have the exact same version number refer to two different versions.