The article does a good job of highlighting some problems of versioning but I don't think the solution it proposes is any better.
The format of Product A Version B.c seems to be most actionable as long as it's consistent.
A could be a major shift in the product. So something like Windows 98, Windows 2000, iPhone 3 and 4, Android Gingerbread and ICS.
Version B would update whenever it's unstable and possibly breaking. So a version 2.0 or 3.0 would introduce lots of new things, but new things tend to be unstable, even after extensive testing.
Version .c is more stable as the number increases. So a version 4.88 is more stable than version 4.81
I don't see how more dots (e.g. version 4.81.2 of 4.81c) are actionable.
As the article brings up, the problem is when the defaults highlight to a new shiny unstable version instead of a stable older one. So the defaults should point to the highest c number, just a version below B. If the latest build is Version 7.2, the stable build might be 6.214.
The format of Product A Version B.c seems to be most actionable as long as it's consistent.
A could be a major shift in the product. So something like Windows 98, Windows 2000, iPhone 3 and 4, Android Gingerbread and ICS.
Version B would update whenever it's unstable and possibly breaking. So a version 2.0 or 3.0 would introduce lots of new things, but new things tend to be unstable, even after extensive testing.
Version .c is more stable as the number increases. So a version 4.88 is more stable than version 4.81
I don't see how more dots (e.g. version 4.81.2 of 4.81c) are actionable.
As the article brings up, the problem is when the defaults highlight to a new shiny unstable version instead of a stable older one. So the defaults should point to the highest c number, just a version below B. If the latest build is Version 7.2, the stable build might be 6.214.