4

We are an outsourcing company. We develop firmware and software for our client. They have a hardware engineer team with whom we, firmware developers, work.

Our client has a strictly defined process to release a firmware. A change in firmware version number has a big impact in that process. When we release a firmware to them for testing, the hardware engineers test it first. Then another SQA test it. Finally, the product is released to customers.

Sometimes, when the change is minor in a new release, our client insist to keep the version number same as the last one. Say, latest release from developers (not released to the customers) had version number 10. Then we found a place for optimization. Or may be slightly change in behavior of the firmware in a very special case which may or may not be visible from outside. When we propose them that we found these places for minor improvements, they insist us to do the changes but keep the version number 10.

We insist that every firmware we release must have distinct version number. We pointed out several common pitfalls if we don't change the firmware version number with every release. They say that they understand why it is necessary. Yet they force us to keep the version number same. Keeping the version number same will help their strictly defined process of releasing firmware to customer end.

We manage the code in our own repository (SVN). We strictly tie a given version number to a given revision number. The version number is stored in the EEPROM of the product our client release. There is defined 2 bytes where the version number is stored. The PC software that reads version number always reads the 2 bytes and display the version number in PC monitor. There is no other way to define version number. They won't change the software that read version number and they won't allocate more memory to introduce another version number that developers can only use.

I'm about to change a firmware and release with the modifications today. I've got another request to keep version number same as previous one. I want to email several unbeatable arguments again what problems we might face if we keep the version number same as previous release.

How can I convince my client not to use same version number?

Donotalo
  • 1,219
  • 1
  • 12
  • 19
  • 4
    I hope you're open to some sort of technical solution, because if this is a people problem, you're probably asking in the wrong place. The way you've couched your question, there seems to be no solution; like Captain Kirk, I don't believe in the no-win scenario. There's always a solution, even if the solution is "This is what they want; accept it." – Robert Harvey Feb 15 '12 at 05:14
  • Remember Java 2 version 1.4.2? How about Windows 7 service pack 2. And right now, I'm using Internet Explorer 8 version 8.0.6001.18702. Would such a scheme work for you? – Dawood ibn Kareem Feb 15 '12 at 07:39
  • @DavidWallace: i'm sorry as i think i've chosen wrong words may be. i'm not looking for a way to define version numbers. here is my question, picked from the last sentence: How can I convince my client not to use same version number? – Donotalo Feb 15 '12 at 07:48
  • @RobertHarvey: well i've seen plenty of "how to explain"-ish post such as http://programmers.stackexchange.com/q/134861?hq=1 in programmers. i'm also looking a way to convince my client not to use same version number. English is not first language so probably I failed to explain what I want. – Donotalo Feb 15 '12 at 07:49
  • @Donotalo - sorry that I didn't make myself clearer. You let the client know "this is still version 10" (like "this is still Java 2"). But YOU KNOW that it's actually internal-version 1.4.2 of version 10. If the client doesn't want to know that it's really 1.4.2, you don't need to tell them. – Dawood ibn Kareem Feb 15 '12 at 07:55
  • 1
    There is only one reason that you need: if you do not change the version number with each new release, you cannot trace bugs and issues back to an actual specific build. If you really have to, you can make this about money: "if we are not allowed to increase the version number our maintenance cost must go up by x% to backtrack trying to find the actual release that issues appeared in". – Joris Timmermans Feb 15 '12 at 08:34
  • @DavidWallace: there is only one place where version number can be placed and retrieved. otherwise, we'd have a solution. – Donotalo Feb 15 '12 at 12:53
  • @MadKeithV: i've mentioned that our maintenance will be difficult with today's build. thanks. – Donotalo Feb 15 '12 at 12:53
  • @Donotalo - "difficult" means nothing to the customer or management. Make it about time, money or quality, and make a hard case with actual numbers. – Joris Timmermans Feb 15 '12 at 13:36
  • Why is the versioning so important to you? You client has a defined process, and presumably reasons for it (which you don't get into), that you want to make major changes to for your own convenience. (You don't even say what field your client is in, but some areas have very strict regulatory requirements, particularly in embedded.) You've said that maintenance will be more difficult, and hence probably more expensive, but that may be a good tradeoff for your client. They're the customer, and if you want their money you need to provide something good for them. – David Thornley Feb 15 '12 at 15:19
  • @DavidThornley: It already happened few times that they say they've found a bug in version X and we find the bug has been resolved in latest iteration of version X, in case when there exist 4/5 builds with same version number "X". As others have mentioned, there exist problems with multiple builds having same version number, from developers perspective. – Donotalo Feb 15 '12 at 15:27
  • 3
    @Donotalo: The developers' perspective is irrelevant in this case: you need to be able to deal with the customer's perspective or stop doing things for that customer. In this case, you wasted some time, which you presumably billed for (or accounted for by charging more for support). The customer now has a problem in their own versioning, but that's their problem, not yours. The customer does not care about your technical concerns, except insofar as it costs them money or reliability or something. Again, what skin is it off your nose if your customer does things that way? – David Thornley Feb 15 '12 at 16:32

2 Answers2

6

You can't and you shouldn't.

If you've already done your due diligence in educating them of the pitfalls of not properly versioning the firmware, then any sour spots that they run into sits squarely on their shoulders, not yours.

I'd ensure that for every request asking for an unversioned product that I send them the same e-mail detailing the "unbeatable arguments". This is a cover-your-own-arse step to ensure that you have a paper trail to avoid any he-said-she-said arguments down the road (and make sure you hang onto them permanently for obvious reasons).

If you're the outsourcer and you want a happy client, you fulfill their requests (with that paper trail). It's not your product, it's theirs. If they maintain they want an improperly versioned product, that's their prerogative.

Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
2

So create and maintain your own internal minor version/build number in the EEPROM.

All you need is one byte; that will give you 256 iterations before your client finally OK's a change to their version number. When that happens, you can start counting again from zero.

The PC software doesn't have to display the build number. You can get that using a special outboard utility that you write, if you need it.

Think outside the box.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Our client won't allow any EEPROM byte for that. I'm not looking for solution. As you've mentioned, there is no solution. I'm looking for suggestions by which my client may convince and can't deny. – Donotalo Feb 15 '12 at 06:09