Versioning for shipping components

[TLRando]

Okay, so this is really a question I feel very odd even having to ask. No, I ain't no noob, but I am worried that someone I am working with very much IS. Or there's some other, less polite explanation at work. Please don't laugh, because this is a real situation at a real company. Well, okay, laugh if you must.

I work at a significantly well recognized software manufacturer. a Project manager there wants to ship a web-downloadable API library that allows easier programming against our very successful product. Indeed, Marketing is on board to make this "the next big thing" for our third-party partners.

The deal is, this guy wants to ship the downloadable, the installer, and the component documentation with NO version indication at all. That's right, NONE. He wants to rely on only the build number inside the DLL.

Yes, you read right. The one that ships in a few months will be called "The Great API", and so will the updated one in 9 months, and the version in 12 months, and again and again, even out to as much as ten years. All with ZERO indication of when the thing was published or updated or anything.

The guy's rationale is that it will mean they won't have to change the strings in the installer. Except that all the other files WILL have to change, so I'm not buying that's it's significantly easier.

As if from Zoolander, "I feel like I'm taking crazy pills".

Am I off the mark to continue trying to convince this guy that you can't just ship multiple...if not many iterations of a component library without making it easy for people to know which one they're downloading; which one they're installing, and which one they're using?

I'm perfectly happy just letting it go if there's someone who can make a reasonable case why readily-discernible version identifiers (like "Version 0.9" or "June 2009") are not needed.

So, am I loonie? Or is this just bizarre?

Thanks for your advice here!

[Rashakil Fol]

That doesn't seem _crazy_ to me. If you ask me, technically speaking, version numbers should correspond to the structure of your branches in version control. I don't know what "build numbers" refers to, but if the build number corresponds to version control, it's a reasonable system.

For example, at my workplace, we have "version numbers" which are really just names for release branches, like 3.0, 3.5.m1, 3.6. We identify a particular build with a version number plus an incremented build number, so the build will be known as something like 3.0-build05.

With that, it's trivial to see which revision corresponds to a given build, because it's a tag in the version control system.

The rationale involving updating the installer really is a sign of incompetence though. He's worried about changing strings in an installer? Are you not automatically generating those strings? That's retarded. If your manager can't grasp the concept of basic build scripts for stuff like that, there might be other mental problems. Where do your build numbers come from? Surely you can configure an installer with the same information.

[TLRando]

Thanks, Rashakil.

Thankfully my manager is not the same as his. My manager got all wide-eyed, shook his head in disbelief and just said "fight on!" when I described what was going down.

Like you suggest, I had asked the programmer why he didn't just use that build number, since its already applied to the component he's shipping.

You're right that the release and version should come from the branch versions, and for all our other shipping products, they do! Indeed, the DLL has a version number.

He just refused to show any kind of release/version identifier to customers in any meaningful way when they download, read about, install or uninstall it. He really did claim that he wanted to avoid the "work" involved in updating the visible strings. Even though every other thing in the installer had to be updated for any release.

I suspect this guy (imagines himself) a whiz-bang Web services programmer turned project manager, and he's intimidated by the idea of writing an installer. Of course, why that's an issue, I'm not sure. We have a whole build team at his disposal! They handle all our other installers for us. Heck, they even built one for my team where I put the files in a folder with a tiny config XML file, and boom it builds a new installer during the nighly builds. I even offered to build the thing FOR him. Go figure.

In a positive twist, he made the tactical mistake of including his second-level manager on a related thread, so I included that guy and the Marketing director, urging him to reconsider. Sure enough, a terse, not at all happy reply eventually came back saying he was going to "discuss" it with his own manager and get back to me.

Yeah, I think that like it or not, sanity will soon prevail with a ball-peen hammer on this dude's installer. Thus making a whole raft of people's lives a tiny bit easier.