問題タブ [release-cycle]

私はソフトウェアをオンラインで配布していますが、バージョン番号をより適切に定義する適切な方法があるかどうか常に疑問に思っています。

答えにABCDがあるとしましょう。各コンポーネントをいつ増やしますか?

D mod 2 == 1 など、他のバージョン番号のトリックを使用していますか?これは、社内リリースのみであることを意味しますか?

独自のバージョン番号を持つベータ リリースはありますか、それともバージョン番号ごとのベータ リリースはありますか?

バージョン番号が 1 よりも大きいソフトウェアをリリースすることは嫌われますか?

たとえば、技術に詳しくない一部の人々は、バージョン番号の高い競合他社の製品を、私のソフトウェアがそれほど優れていないことを意味すると見なす場合があります。

私は製品開発会社で働いています。最初に内部リリースを行い、次に公開リリースを行います。他の製品開発会社がどのようにリリースを管理しているのでしょうか。リリース番号はどのように付けますか？ソース管理にタグを付けますか？

個別にリリースされた複数のアーティファクトに影響を与えるバグの変更やテスト作業をどのように追跡していますか?

コード共有は、コードを介したパスの総数を減らすため、優れています。つまり、より少ない変更とより少ないバグ (またはより少ない変更でより多くのバグに対処) でより多くの影響を与えることを意味します。たとえば、同じファイル処理パッケージまたはモデル パッケージを使用する検索ツールとインデクサーを構築する場合があります。

変更がすべての適切なコンポーネントでテストされ、どの変更がどのリリース済みツールに含まれていたかを追跡できるようにする必要があります。また、すべてのアプリケーションで同時に変更をリリースする必要はありません。

目標: 1 つのバグをテストし、リリースされた各アプリケーションに対して個別に追跡をスケジュールします。アーキテクチャを理解する自動化されたシステムにより、正しい選択を行うことができます。

バグ分割リリース シナリオ:

ユーティリティ ライブラリのパフォーマンス修正を含む検索ツールのパッチをリリースする場合があります。検索ツールにとって重要な修正プログラムは、インデクサーではあまり見えないため、次のメンテナンス リリースまで待つことができます。検索パッチで 1 つのバグをスケジュール、追跡、リリースし、インデクサーの次のメンテナンス リリースまで延期したいと考えています。

そのため、追跡システム (JIRA) でバグを作成すると、魔法のように複数のオブジェクトになるようにしたいと考えています。

• 問題を説明し、開発作業を追跡する主要な問題
• テスト作業を追跡し、影響を受けるアプリケーションごとにこの問題がどのようにリリースされたかを追跡できるようにする一連のタスク。

どの変更がどのリリースに影響を与えるかを知らずに、または人々に多くの重複したバグを入力させることなく、より多くのコード共有を促進するために、コード共有のユーザー エクスペリエンスを低労力で作成するにはどうすればよいでしょうか?

Eclipse から Linux ディストリビューションまでの大規模なプロジェクトは、この種の問題に直面しており、どのように解決したのか疑問に思っていることは確かです (次はそれらについて詳しく説明します)。

この種の状況を経験したことがある人はいますか?どのように対処しましたか?

少なくともガンマがベータとアルファの後に来ることは非常に直感的です。

しかし、CTP、RTM、およびプレビュー リリースはどうですか? 最初と最後はどっち？

MEF (Managed Extensibility Framework) は現在Preview 5リリースですが、それが Alpha 前のリリースなのか、Beta、CTP、RTM の後のリリースなのかはわかりません。本番コードでプレビュー リリースを使用しても問題ありませんか?

これらのリリースの違いは何ですか? の違いを知ることに特に興味があります。

• RTM
• CTP
• ベータ
• RC
• プレビュー

リリースします。

どこでもリリースごとに意味が異なるようです。

それともリリース候補？私のgoogle-fuは私を失敗させます。

Spring の 3.0 バージョンがGAリリースになりました。それ以前に、3.0 RC1、RC2バージョン、Spring 3.0 M2バージョンがリリースされました。GA、RC、M バージョンの違いは何ですか?

iOS のベータ リリースに対してアプリをテストできるのは良いことですが、Apple がプッシュしているベータ リリースの数は、いくつかの点で私にとって慈悲を煩わしさに変えているようです。

• SDK および iOS イメージの膨大なファイルのダウンロード
• 次のベータ版で壊れる可能性があるものを修正し続ける必要があります
• 多くの場合、Apple のリリース ノートだけでは、自分のアプリが機能しなくなった理由を理解するのに十分ではありません
• NDA により、Web で回答を見つけることがはるかに難しくなります

それで、他の iOS 開発者がこれにどのように対処しているのか疑問に思い始めました。Apple は、頻繁にベータ版をリリースしてアプリをテストするための推奨されるアプローチを持っていますか? 新しい iOS の修正をいつ Apple に提出すればよいですか (次のベータリリースで壊れる可能性があることに注意してください)。

iOS のベータ版リリースに対してアプリをテストするためのもっともらしいアプローチを提案または指摘してもらえますか?

Java 8 に関するニュースがますます増えていますが、Java 7 が多くの場所で採用され始めたばかりです。たとえば、私の職場では、Java 7 を使用している人もいますが、まだ Java 6 を使用しています。

私は疑問に思っています-Javaの利用可能なバージョンの制限は何ですか? 新しい Java 仕様が展開され、実装される頻度はどれくらいでしょうか。Java 7 はまだ進化していたので、Java 8 はずっと先のことだと思っていました。

たぶん、私が見逃しているこの種の詳細については、適切な (tl;dr 以外の) 公式ソースがあるかもしれません。もしあれば、お知らせください。