私のチームが取り組んでいる内部アプリケーションは、現在バージョン10.y.z.build_number.
次のリリースが十分に重要であるか、10.y+1.z.build_numberまたはそうすべきかについての議論の中で、10.y.z+1.build_numberシンプルに保ち、バージョン番号をカレンダーに合わせることを提案しました.
たとえば、次のリリースは で、13.8.1.build_numberこれは 2013 年 8 月の最初のリリースを表します。9 月のリリースは です13.9.1.build_number。
アイデアは今のところ破棄されています。
有料のアプリケーションの場合、1 番目の番号があれば、無料のアップグレードを伴うリリースと有料のアップデートが必要なメジャー リリースを簡単に区別できると想像できます。x+1.y.z支払われ、x.y+1.z無料になります。
簡単な検索の後、Jeff Attwood のWhat's In a Version Number, とにかく?を見つけました。.
しかし、無料の内部アプリケーションの場合、カレンダーに合わせたバージョン番号の弱点は考えられず、シンプルさの美しさが私に語りかけます. Jeff Atwood の投稿に対するコメントの 1 つに次のように書かれています。Microsoft Office 2003 は、Microsoft Office 11 よりもはるかに意味のある名前です。
質問: 私のビジョンは熱狂によって曇っていますか? また、カレンダーに合わせたバージョン番号に関する既知の問題はありますか?