insanity vendor release management

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 4.2.2.1), 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 (4.2.2.1), 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.

This entry was posted in General. Bookmark the permalink.

7 Responses to insanity vendor release management

  1. Ross says:

    Am I the only one that finds irony in a bunch of typos in a rant about release management?

    Of course, that’s probably more of a QA issue…

  2. jrochkind says:

    I did not apply any QA to that post. Fortunately, it having lots of typos in it doesn’t make anyone’s job any harder or harm any patrons, nor was anyone paying me for it. Instead, i wrote it in a moment of frustration while busy with 6 other things too.

    So let’s be clear, I make absolutely no guarantees that my blog will be typo free, or even that I’ll try to make it typo free.

  3. Karl Fogel says:

    If you’re referring to the “teh future” typo, I think that’s a deliberate joke (Google for the reference).

  4. jrochkind says:

    Thanks for the defense Karl, but no, it was a typo. I’ll leave the typos for posterity, so Ross’s egg on my face will continue to make sense. Ross is great, but has become somewhat sensitive to criticism of vendors since going to work for one.

    But, yes, I’d emphasize, I do not think it is at all inappropriate to expect a higher standard of quality control for vendors we pay a lot (an awful, awful, lot) of money to, than from free open source projects. Isn’t that why we’re paying them an awful lot of money? So, yeah, some open source projects I work on aren’t as stable and high quality as I’d like (I’m doing my best, and I inherited the code from Ross in the first place :) ), but I haven’t taken anyone’s money with any assurances to the contrary. And my biggest complaint here was NOT about the bug in their code (there will always be bugs, although they can be reduced by good practices), but the release management insanity (if you have to release bugfix releases all the time, that’s one thing. If you re-use version numbers to do so, that’s worse).

    [So I guess I should release a 1.0.1 version of this blog post, with typos fixed? If release management actually mattered for this blog and it was worth my time. Usually I just fix typos without telling anyone. Other bloggers I’ve seen use strike-out style so you can see it’s been changed, a light-weight form of ‘versioning’ apropriate to it’s importance in a blog post. In the Code4Lib Journal, on the other hand, we do not make any changes to published articles without making it clear we’ve made changes, because we think versioning more important in a ‘published journal’ than an informal blog post.]

    Hey Karl, how’s it going, you probably don’t remember me, but we overlapped for one year in the Oberlin CS program.

  5. Karl Fogel says:

    Hey, I do remember, yes! How are you?

    Going pretty well; I still work in open source software, and also do some non-profit work in bringing open-source principles to areas outside software.

    What it’s reasonable to expect from various release sources (paid or unpaid, proprietary or open source) is a giant philosophical sinkhole into which I will politely refuse to leap :-). However, I certainly agree that it’s insane to re-use release numbers for different releases or patches!

  6. jrochkind says:

    And the vendor responds. Thanks Ex Libris!

    *******

    Dear Jonathan, Breck, MetaLib customers –

    We apologize for the inconvenience caused with our recent change and re-issue of the MetaLib 4.2.2 Service Pack.

    You are correct, and your points are noted. If, in the future, we face a similar situation we will issue a new Service pack with appropriate version numbering.

    We appreciate your feedback and suggestions; they help us continue to improve our processes.

    Best,

    Karen

    ——————————————————————
    Karen Groves
    ILS & MetaLib Product Management
    Ex Libris, Inc.

    Phone: 617 332 8800 ext. 529
    Email: karen.groves@exlibrisgroup.com

  7. Ross says:

    Well, I was just making light of the situation, not trying to discredit Jonathan at all or come to the defense of vendors (when, truthfully, Jonathan, my opinions haven’t really changed about vendors much).

    I mean, you’re right about the ridiculousness of two different releases with the same release number. And you are also right that we should expect a little more professionalism from our vendors than we do from our blogroll or our favorite open source openurl resolver.

    And the sad thing is that we don’t, generally.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s