依存関係を管理するために npm を使用して node.js で SaaS アプリケーションに取り組んでいます。バージョン番号についてどうするかを決めようとしています。私たちのリリースモデルは、マーケティングバージョンではなく、機能を市場に出し、準備ができたらリリースすることです。
package.json のバージョン フィールドに関するアドバイスを探しています。アプリを npm レジストリに公開しないので、必要なバージョン番号を実際に使用できます。1.0、1.2、2.0 などの典型的なバージョン番号を維持したくはありません。リリースは単に準備ができたら出荷されるプロジェクトなので、「RELEASE_20130104」のように、日付がより良いバージョンになりますが、npm ではpackage.json の version フィールドは、semver ルールによって解析可能である必要があります。
コミュニティの他のメンバーが SaaS npm ベースのアプリに対して行ったことに興味があります。
要件：
- 簡単 - 1.2.0 か 2.0 かの議論で時間を無駄にしたくありません。ちょうど次のリリースです。
- npm バージョンの構文規則を満たす必要があります。
あると便利なもの:
- SVN ブランチとリビジョン番号の抽出など、ビルド プロセスを通じてスクリプト化可能。
- バージョンとは、リリース日などを意味します。
私が思いついた解決策：
- semver major.minor.patch パターンに厳密に従ってください。これには、リリース タイプごとに個別のスクリプトが必要となり、プレリリース ビルドにとっては悪夢となります。
- リリース日を「2013.01.04」のようにsemver形式で表現する
- 「21484-BugFix21」のような SVN リビジョン番号 + ブランチまたはタグ名。欠点は、非リリース ビルドのバージョンでは、どのリリース バージョンから分岐したかがわからないことです。
- ダミーのバージョンを選択し、「1.0.0」のように決して変更しないでください。"appRelease": "2013.01.04" のように、別のフィールドで必要な形式でバージョンを追跡します。
正しい答えも間違った答えも期待していません。たくさんの解決策があります。他の人が過去にどのようなアプローチをとったかを知りたいと思っています。