Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
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.