質問: joomlaバージョンのプレリリースサイクルはどのように機能し、ベータ段階で拡張機能をテストできますか? 私は ソフトウェアリリースサイクルマップ (wikipediaにあるものと同様)を探していますが、joomlaです!私は特にではありませんリリース予定日を探していますまたはこの回答の一部としてのサポートの長さ確認したい(または、誤りがある場合は、プロジェクトリーダーシップチームが使用している用語を含め、以下の情報を正確に入手してください)。 アルファ ベータ リリース候補(rc) マーケティングへのリリース(rtm) 一般提供(ga) 製造 その理由は、ベータ版に対してクライアントのサイト(さまざまなプロバイダーからの拡張機能が含まれている)をテストしたいからです。別の開発サーバーをセットアップし、ライブサイト(パスワードでディレクトリを保護)のクローンを作成し、joomla!をアップグレードできます。ベータ版のコア。特定のベータリリースに更新するようにクローンテストサイトを構成する正しい方法について、いくつかの手順が必要です。joomlaにはドロップダウンがあります!上記に関連して、どのバージョンに更新するか(つまり、「テスト」とは何ですか?)がわかるように、整合していないように見えるか、レベルの説明が提供されていない構成(j!2.3.2)を更新します。 。「カスタムurl」を入力するオプションがありますが、ユーザーがベータ版テストにアップグレードできるかどうかはわかりません。ベータ段階でテストを支援する方法について少し迷っていますが、これはjoomlaにとって価値があると思います! cms、拡張プロバイダー、そしてもちろんサイトの所有者。これは、リリース段階の早い段階で複製されたライブサイトをテストし、早期にバグを報告して解決する機会を提供するためです。もちろん、テストはさまざまなベータ版からrcまで続きます。そのため、joomlaの設定方法を知る必要があります。テストされているjoomlaの特定のバージョンに更新するための設定の更新。また、私は経験がほとんどないので、間違った道を進んでいる場合は、より良いアプローチを明確にして提案してください。最終目標は、ベータフェーズとrcフェーズを通じて早期かつ継続的にテストでき、joomla!にバグのフィードバックを提供できることです。プロジェクトリーダーシップとエクステンションの開発者、そしてその後、クライアント用の更新cmsでライブに移行するスムーズな移行があります(つまり、ゲームの初期段階で潜在的なバグをキャッチして伝える方法を理解しようとしています)。
回答: 以下の定義はセマンティックバージョニング( http://semver.org/ )の定義であり、joomla 3.3以降でjoomlaが使用することに注意してください。したがって、パッチリリースのみの場合、通常はストレートリリース候補のみとなります。マイナーリリースでは、いくつかのベータ版(通常、私たちがフォローしている特定の番号はありませんが、2/3より大きい)をリリースし、その後に1つ(または重大なバグが見つかった場合はさらに多く)のリリース候補が続きます。メジャーリリースでは、アルファ、ベータ、リリース候補のセットをリリースします。ベータ版をテストしたい場合は、いつでも完全に許可されています。ベータ版にはリリース候補へのアップグレードパスがないため、メインサイトではこれを行わないでください(ベータ版から別のベータ版へのアップグレード時にエラーが発生する可能性があります)。アルファ、ベータ、またはrcをテストするには、joomlacodeから特定のパッケージをダウンロードすることができます(たとえば、ここにjoomla 3.3のベータ3へのリンクがあります( http://joomlacode.org/gf/project/joomla/frs /?action = frsreleasebrowse&frs_package_id = 688 )および拡張機能マネージャーを介してインストールするか、joomla更新コンポーネントをテストに設定します(この方法では、最新のテストバージョンのみを取得します-これは最新のベータ版またはrcなどになります)。バージョンを指定することはできません)joomla更新コンポーネントのカスタムurlは、別のxmlファイルをポイントすることを許可するだけです。つまり、テストするバージョンを選択することはできません。 joomla updateコンポーネントの構築方法では、これは不可能です。コンポーネントの最新バージョンを選択するように設計されています。