Simplify the software version numbering scheme.

As HCL has a totally different and more progressive from what IBM had, it would be great to make the software version numbering more closely match this change. The current Notes version numbers lend themselves to a slow pace with an occasional major release of new features followed by a long series of versions focused on bug fixes. The version numbers seem overly complicated and add a resistance to upgrading by de-emphasizing the value of minor releases ( the x value in a release n.0.x or any Fix Pack) while over-emphasizing the effort in upgrading to major releases ( x.0 ). Current version numbering system also mostly ignores the middle value ( the x value in release n.x) I think it would help to adopt a version numbering scheme that accurately reflects the value and effort of new versions and simplify the version numbering system.

First, eliminate the digit after the first decimal point. If you are never going to use it, then just drop it. So V12.0.1 would be V12.1 . Ultimately, whether it is V12.0.1 or V12.1 has no functional effect.

Next, stop using FP and just make it another point-release.
So V12.0.1 FP1 becomes V12.1.1 or better yet, V12.2 . Again, whether it is V12.0.1 FP1 or V12.0.2 or V12.2 has no functional impact. Keep it simple.

Simplifying the version system will improve the language around versions and upgrades. It will simplify it for existing customers and make the software more appealing to new customers.

Which is better from a marketing perspective:

9.0.1 FP1
9.0.1 FP2
9.0.1 FP3
9.0.1 FP4
9.0.1 FP5
9.0.1 FP6
9.0.1 FP7
9.0.1 FP8
9.0.1 FP9

or

9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9

This is about marketing and creating the perception of HCL's new, more nimble and intensive software development culture around the products and simplifying it from the customer's viewpoint.

-David Hablewitz