5

しばらくの間、ソフトウェアのバージョン管理に苦労しています。命名規則について話しているのではなく、ビルド システムでバージョンをリリースまで実際に適用する方法について話しているのです。

私は通常、major.minor.maintenance-[リリース タイプ] 1.0.2-rc1 を使用します。

問題はバージョン番号の管理です。私は多くの方法を試しました (ビルド ファイル、プロパティ ファイル、データベースなどに貼り付けます) が、実際にうまく機能するものは見つかりませんでした。

私が思いついた最も近いものは、ここに文書化した Jira の使用です: http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html

誰かがこれについて何か良いアイデアを持っているかどうか疑問に思っています。また、人々がバージョンのリリースをどのように処理するのか疑問に思っています....つまり、バージョン 1.0.0-rc1 をリリース/展開すると、このリリースで見つかったバグが発生し、1.0.0 (次の/製品リリース) にログインします。

4

6 に答える 6

4

Microsoft は<major>.<minor>.<patch>-<build number>(またはバリエーション) を使用します。

使うのが好き<major>.<minor>.<buildnumber>

于 2008-11-04T19:02:31.150 に答える
2

これはおそらく死んでいる投稿ですが、とにかく 2 セント追加します。ビルド番号は、それを見るすべての人にとって何かを意味するべきだと私は考えています。したがって、個人的には、これがバージョンに名前を付ける良い方法だと思います。

major.minor.patch.revision - 例: 1.1.4.2342

メジャー/マイナー番号は一目瞭然です。しかし、3 番目の数字の観点からは、顧客にとって何かを意味する必要があります。お客様にこの新しいバージョンをリリースしましたが、いくつかのバグを修正したばかりなので、新しいマイナー番号の価値はありませんでした。そのため、パッチ番号を増やしました。

4 番目の数字は通常、顧客にとってまったく意味がないので、自分だけでなく、それを見た会社の他の人にも役立つようにすることもできます。私たちにとって、その番号は SVN リビジョン番号です。どのリビジョンがそのバージョンの原因であったかを正確に教えてくれるので、いつでも取り出して再作成することができます。分岐コードも明らかにこれを実現しますが、100% 確実ではありません。

また、すべて数値のバージョン番号のもう 1 つの利点は、ほぼすべての継続的なビルド システムに簡単に統合できることです。

とにかく、それは私の 2 セントです。

于 2009-03-18T22:26:02.013 に答える
2

私が働いている場所では、Maven システムを使用しています: artifact[-major-minor-revision][-SNAPSHOT] これにより、すぐに変更される「進行中」のバージョン (SNAPSHOT) と、正式にリリースされたバージョンを開発できます。 . いくつかの例は次のとおりです。

email-services-1.0.0-SNAPSHOT.jar

  • 電子メール-web-2.3.11.war
  • crm-2.5.0.ear

    • SNAPSHOT が含まれている場合は、完全な一連のテストに合格していないか、単なる開発者の実験です。SNAPSHOT がない場合は、リリース候補です。私たちはリリース候補のリポジトリを維持しており、テスターが満足すれば、最新のものを展開するために送信します。

    これらはすべて、Maven のビルド ファイルにいくつかの単純なエントリを追加するだけで管理できます。Maven2 チュートリアルを参照

    于 2008-11-04T19:40:10.030 に答える
    1

    Jira/Bamboo ソリューションで +1。(私の目的のために) 含めるビルドに関する唯一の追加情報は、Subversion リリースですが、タグ付け操作は私が望むものの 80% です。

    リリース/バージョン情報を手動で維持するのは大変な作業です。JIRA に任せるのは素晴らしいアイデアです。

    最後の質問では、バグ/欠陥が記録される場所とreleasingバージョンについて:

    • 欠陥/問題は、それが表示されたリリースに対して記録されます。1.0.0-rc1 の欠陥が 1.0.0-rc1 に対してログに記録される
    • JIRA には、予定されているリリース (この場合は 1.0.0) を持つ「Fix-For」フィールドがあります (または追加した可能性があります)。
    • 欠陥/問題が深刻な場合は、別の 'rc' リリースを追加する必要がある場合があります。
    • リリースは、未解決の重大な欠陥/問題がなく、顧客 (または管理者) が残りの問題を延期できることに同意した場合に行われます。

    JIRA を介してこれを管理する利点は、リリースの追加、変更ログの生成などがかなりうまく自動化されていることです。

    于 2008-11-04T22:27:43.170 に答える
    0

    Major.Minor.BuildDateNumber.DailyBuildNumber

    メジャーとマイナーは私たちが設定し、適切と思われるように手動でインクリメントします。

    BuildDateNumberは、プロジェクトの開始からの月数に100を掛けたものに、現在の月の日数を加えたものです。

    DailyBuildNumberは、毎日午前0時以降、ビルドごとにゼロから増分されます。

    たとえば、プロジェクトがその年の1月1日に開始された7月10日のリリース5.2の4番目のビルドには、バージョン番号があります。

    5.2.710.3

    これはすべて、Nantのバージョンタスクによって計算されます。

    これにより、バージョン番号が一意に保たれ、インストールがいつ構築されたかをすばやく計算することもできます。

    于 2009-06-11T15:48:43.207 に答える
    0

    <major>.<minor>.<buildnumber>また、ビルド サーバーの CruiseControl/(.Net) を使用してこれを管理します。また、Wix と CruiseControl Config を使用してメジャー マイナー番号を管理します。これも手動でインクリメントしますが、ビルド番号はビルド サーバー上で自動的に発生します。メジャー/マイナーを自動的にインクリメントするルールを設定することもできると思います-特定のリリースレベルに名前を付けるときに開発者が意識的に考える必要があるように、手動でそれを行う必要があります.

    于 2008-11-04T19:13:33.420 に答える