The problem with using letters for Sonar patch revisions

So, Sonar X3c needs a fix to correct a small problem with console emulator hum.  People already have it in their heads that X3d is going to have the much anticipated video enhancements.  So what is CW to do?  Release X3d.a?  Or X3d.01?
 
If We'd had X3.1, X3.2 and X3.3, CW could release a quick fix X3.3.1, and it would not confuse those waiting on X3.4.
 
Just my thoughts out loud here, but doesn't using a letter for patch revision versions paint the bakers into somewhat of a corner?

Got to admit that what it is called doesn't concern me. I can understand how it could cause some confusion but honestly I think it is a non-issue. I've had this conversation with a team of software developers and it struck me then that it was kind of bizarre. At the time I think I said something along the lines of "If the flaws are fixed nobody gives 'blah' what we call it."
 
Just my opinion though...
 
Regards,
 
 

I personally like more the updates in any convention used (i.e., combinations of letters and numbers or whatever) than quick fixes. On the other hand, we are already used to XNx convention since X1 and that is one of the reasons for using conventions. 

Traditionally, letters have been used for unreleased builds, in-house versions for QA to evaluate. Using a letter designation makes the release sound more trivial, as if the only fixes were some un-dotted i's. 
 
Note that internal file versions still follow traditional major.minor.build numbering schemes. The letter designations are purely a marketing gimmick.
 
I blame it on Microsoft, which screwed everything up when they released Windows 95, making it acceptable to abandon a version numbering scheme that had been working just fine for half a century prior. This is what happens when engineers yield control of a company to Marketing.

I think what it boils down to is that most people aren't software engineers and probably identify more with letters or words than numbers. That is to say, they have a harder time keeping track of a decimal naming convention in their minds than a letter based one. Decimals are math and hence scary.

Consumers think of release numbers as an indicator of forward progress. I've heard many declare that they won't buy any X.0 release because it probably isn't done yet. Some clever developers simply call their first version 1.1 rather than 1.0 for that reason, or even 2.1. Microsoft's first version of SQL Server was 6.0.
 
I think the Firefox team just took that idiocy one step further, with a major release every few weeks. "Look: it must be better, we're already at version 24 and those losers at Microsoft are only up to 10!" Chrome must be even better, it's at version 28!
 
Native Instruments takes the opposite approach, with "minor" releases that are incompatible with the previous minor release. Libraries created under Kontakt 4.2.3 would not run in Kontakt 4.2.0. NI has never implemented even the most trivial enhancement without making sure that it a) cost money and b) broke compatibility with previous versions. 
 
Other audio software companies are just as guilty. Some changed the major version number - or in one case, even the name of the product - when all they'd added was 64-bit support, just so they could charge for the "upgrade". 
 
Cakewalk's far from the worst offender, although it broke the traditional numbering system with SONAR 8.5, which should have been called 9.0. It was a paid upgrade, not a fix release. 8.3, OTOH, was treated as a fix release. Then they went all Microsoft on us and called the next version X1. At least they didn't call it "SONAR 2010".
 
 
 
At one time a car company adopted the slogan "...where quality is Job 1". I had a sign in my office at the time that read "Microsoft, where quality is Job 1.1"