This actually hit my previous company in a software context.
We would number our hotfixes sequentially. Many would be items demanded by a single client, so would get deployed as hotfixes only to that customer's site, and just rolled into the main trunk for the next quarterly release for everyone else. Clients would always be notified about hotfixes going onto their live sites.
One savvy client noticed the hotfix numbering sequence. Naturally, that ensued quite a number of extremely awkward discussions as they would regularly ask why our software needed so many hotfixes (tens per week) and why they weren't entitled to all of them right away.
Solution: a new policy to randomly generate hotfix numbers. Which of course led to the next problem, that now the sequence was not obvious from the names, so dependent hotfixes would sometimes get deployed in the wrong order. Why can't anything be easy...
Just name the hotfixes by day (140222). It monotically increases, and if you do multiple hotfixes in one day, suffix a/b/c etc. Generally you're unlikely to get up to b or c, and there's no clue to how many previous versions there's been.
Leads to longer timestamps though, when you include the HHMM. If you're generally not doing more than one per day, this makes it a little easier - usually six digits instead of ten.
Except that a hotfix number is a human-interaction number, not an automation device. Speaking as someone who has worked on the support phones, I'd much, much, much rather someone only have to read back a six-digit number than a ten-digit one.
That was proposed (with a numeric suffix rather than letter), but rejected because we often would do 3 to 5 in a day, and somebody decided that would still leak too much information about our hotfix workflow. Another aspect would be that hotfixes would sometimes go several days between packaging and deployment (for all your usual megacorp red-tapey risk-aversey reasons), and we didn't want to explain to clients why 20120214 wasn't deployed until 2012-02-21.
i'm sure you (or your employer for that matter) have better things to do than twisting your internal policies to client's dis/liking.
just tell them to fuck off -- in diplomatic speak -- that's what your/a boss is (paid) for.
> why our software needed so many hotfixes
"well. software does not fall from the skies. humans are involved. we can stop fixing shit before you find out and complain, take your money and leave you with crackers. decide!"
I've worked in enterprise software and when customers are paying tens of millions of dollars per year for your software, it's difficult to tell them to fuck off... even more so when your customers all know each other.
Nobody said its easy, we are saying that it must be done or you and the customer will both be unhappy.
I think that far less software businesses fail due to telling their customers to fuck off than vice versa.
At least that is what my anecdotal evidence says. I know of a couple of software businesses that failed because they couldn't get themselves to say no to their customer.
I know of none that told their customer to fuck off and failed.
> i'm sure you (or your employer for that matter) have better things to do than twisting your internal policies to client's dis/liking
I'm sort of at a loss here. The customer is always right, right? If you're deploying software, everything the customer sees is what they're paying for. If it matters to them, and it bothers them (which I can see in this case), I think the good companies fix it, and the bad companies have "better things to do"
"The customer is always right" is an incredibly broken methodology. It works great for a mom&pop shop in a small town… not so much in any other situation.
You could always have a fixed length randomly generated number prefix, with the numbers after that being sequential, making it obvious internally the sequence while obfuscating to the customer.
For example if you did a four digit prefix your first three hotfixes might be:
What you need is random but monotonically increasing sequential version numbers. Add a random number to your last version number, and that is your new version number. ;)
Very good idea. Timestamps do not reveal how many hotfixes are made and are chronological by default. To be sure, there could of course be a central instance providing the stamps and ensuring that no two fixes get the same ... (when several fixes could be made in parallel)
We would number our hotfixes sequentially. Many would be items demanded by a single client, so would get deployed as hotfixes only to that customer's site, and just rolled into the main trunk for the next quarterly release for everyone else. Clients would always be notified about hotfixes going onto their live sites.
One savvy client noticed the hotfix numbering sequence. Naturally, that ensued quite a number of extremely awkward discussions as they would regularly ask why our software needed so many hotfixes (tens per week) and why they weren't entitled to all of them right away.
Solution: a new policy to randomly generate hotfix numbers. Which of course led to the next problem, that now the sequence was not obvious from the names, so dependent hotfixes would sometimes get deployed in the wrong order. Why can't anything be easy...