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?

closed as not constructive by Robert Harvey, user8 Feb 15 '12 at 5:17

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 5: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 7: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 7:48
  • 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 8:34
  • 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

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.

  • Sigh. I can't say that "take responsibility on this build." – Donotalo Feb 15 '12 at 4:57

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.

  • 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 6:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.