このページでは、ASFのソフトウェアリリースに関するポリシーについて説明します。このドキュメントは、ASFリリースマネージャーとPMCメンバーを対象としています。エンドユーザー向けの情報も提供されています。
このドキュメントでは、リリースプロセスの概要を示します。
一般的に、リリースとは、所有するグループを超えて公開されるものです。Apacheプロジェクトの場合、開発コミュニティ（開発に積極的に参加している個人または開発リストをフォローしている個人）の外への公開を意味します。
より狭義には、公式なApacheリリースとは、PMCによって「Foundationの行為」として承認されたものです。
各PMCは、リリースの承認に関するASFの要件に従う必要があります。
投票に関する一般的な情報は、ASF投票プロセスページを参照してください。
リリース投票が可決されるには、最低3票の肯定的な拘束力のある投票と、否定的な拘束力のある投票よりも多い肯定的な拘束力のある投票が必要です。リリースは拒否できません。PMCメンバーによる投票は拘束力がありますが、非拘束力のある投票は強く推奨され、健全なプロジェクトの兆候です。肯定的な投票と否定的な投票を構成するものについては、投票の表明を参照してください。
+1の拘束力のある投票を行う前に、個人がすべての署名済みソースコードパッケージを自分のハードウェアにダウンロードし、以下に説明するリリースに関するASFポリシーのすべての要件を満たしていることを確認し、すべての暗号署名を検証し、提供されたとおりにコンパイルし、自分のプラットフォームで結果をテストすることが必要です。
リリース投票は、少なくとも72時間開いたままにする必要があります。
プロジェクトは公式リリースを公開する必要があり、開発コミュニティ以外に未リリースの資料を公開してはなりません。
ソフトウェアの開発とリリースの準備中に、開発コミュニティがテスト目的でさまざまなパッケージを利用できるようにします。**プロジェクトは、外部の人々を生のソースリポジトリ、ナイトリービルド、スナップショット、リリース候補、またはその他の同様のパッケージではなく、公式リリースに向ける必要があります。**プロジェクトは、開発に積極的に参加している個人または開発リストをフォローしている個人（未リリースの資料に課せられた条件を認識している）をサポートするために、開発者リソースを提供する必要があります。
すべてのASFリリースには、1つ以上のソースパッケージが含まれている必要があります。これは、適切なプラットフォームとツールにアクセスできる場合に、ユーザーがリリースをビルドおよびテストするのに十分なものでなければなりません。ソースリリースには、コンパイル済みコードを含めないでください。
提供されるすべてのパッケージは、切り離された署名で暗号化署名する必要があります。リリースマネージャーまたは自動リリースインフラストラクチャのいずれかによって署名する必要があります。基礎となる実装は、Apacheセキュリティチームが概説した原則に従う必要があります。提供されるすべてのパッケージは、切り離された署名を使用する必要があります。リリースに+1投票する人は、リリース前に切り離された署名ファイルに連結される独自の暗号署名を提供できます（リリースマネージャーの裁量による）。
Apache Software Foundationはオープンソースソフトウェアを生成します。すべてのリリースは、リリースされているソフトウェアに変更を加えるために必要なソース資料の形式です。
ソースのコンパイル済みバージョンをビルドするための適切なツールを持っていない可能性のあるユーザーの便宜のために、バイナリ/バイトコードパッケージは、公式Apacheリリースとともに配布しても構いません。このような場合、バイナリ/バイトコードパッケージのバージョン番号はソースリリースと同じでなければならず、ソースコードリリースとその依存関係をコンパイルした結果であるバイナリ/バイトコードファイルのみを追加する必要があります。
すべてのASFリリースは、ASFライセンスポリシーに準拠する必要があります。この要件は非常に重要であり、完全なリリースを作成する前に監査を行う必要があります。特に、配布されるすべてのアーティファクトには、Apacheライセンスポリシーに従って適切なライセンスのコードのみが含まれている必要があります。
各パッケージには、パッケージの正確なコンテンツを説明するLICENSEファイルとNOTICEファイルを提供する必要があります。LICENSEとNOTICEは、別々にダウンロードされた依存関係など、パッケージにバンドルされていない資料に関する不要な情報を提供してはなりません。
ソースパッケージの場合、LICENSEとNOTICEは配布のルートに配置する必要があります。追加のパッケージの場合、それらは、Javaの「jar」ファイルのMETA-INFディレクトリなど、配布形式のライセンス資料の慣例的な場所に配置する必要があります。
LICENSEファイル¶LICENSEファイルには、Apache License 2.0の全文を含める必要があります。
パッケージが複数のライセンスに基づくコードをバンドルする場合、LICENSEファイルにはこれらのライセンスすべての詳細を含める必要があります。Apacheライセンスが付与されていないコンポーネントごとに、そのコンポーネントの詳細をLICENSEファイルに追加します。コンポーネントライセンス自体は、追加するか、またはライセンスが長い場合など、LICENSEファイルからポインタを付けてパッケージの他の場所に保存する必要があります。
NOTICEファイル¶NOTICEファイルは、Apacheライセンスポリシーの要件に準拠する必要があります。
Apache License 2.0のセクション4(d)も参照してください。
著作権者または著作権者の代理人によってASFに直接提出された作品からなるソースファイルには、適切なASFライセンスヘッダーを含める必要があります。
リリースが承認されたら、すべてのアーティファクトを標準的なApache配布チャネルであるdownloads.apache.org内のプロジェクトのサブディレクトリにアップロードする必要があります。
PMCはプロジェクト配布ディレクトリを担当し、そのコンテンツ全体を説明できる必要があります。ディレクトリ内のすべてのリリースアーティファクトは、コミッター（できればPMCメンバー）によって署名する必要があります。
標準的な配布チャネルにアップロードした後、プロジェクト（またはその他の人）は、ライセンスに従って他のチャネルを通じてアーティファクトを再配布できます。
すべての公式リリースは、archive.apache.orgに永久的にアーカイブする必要があります。
（標準的な配布チャネルへのアップロードにより、この要件が満たされます。アーカイブは副作用として自動的に行われます。）
プロジェクトは、推奨されるポリシー指令または必須のポリシー指令からのずれを理事会に通知する必要があります。
リリースポリシーの変更は、法務部によって承認される必要があります。
追加の公式ポリシーを正式化し、このポリシーから参照する
Apacheのようなボランティアの責任制限組織で実践されている従来のオープンソース開発方法では、「進行中」の作品と一般公開に適した作品を明確に区別する必要があります。明確な線を引く目的は、次のセクションで定義されているように、リリースの作成に関与する正式な参加者に対する保護を提供するという当社の法的戦略を知らせることです。進行中のアセットは、主にプロジェクトの開発リストに従っている、プロジェクト開発に積極的に参加している参加者自身を特定するための制御された配布と見なされます。無制御配布（別名リリース）は、このポリシー文書が対象とするものです。
この区別を曖昧にし、ソースコード管理やナイトリービルドをユーザーが直接操作することを推奨した場合、組織は、承認されたビジネス上の意思決定によって、それらの成果物を現状のまま一般に公開することを承認されていないにもかかわらず、ソフトウェアの修正において独自の判断を行使したApacheコミッターおよびPMCメンバーに法的保護を提供することが非常に困難になります。Apacheの「官僚主義」の大部分とプロジェクトガバナンス構造は、このポリシーの目標を促進するためのものです。そのため、この文書は注意深く検討する価値があります。
このポリシーからの逸脱は、法的保護の有効性またはApacheが役員および取締役を保護するために支払う保険料に悪影響を与える可能性があるため、事前に明示的な取締役会の承認なしに強く推奨されません。ただし、組織としては、効率的な意思決定よりも堅牢でレビュー可能な意思決定を優先しているため、取締役会に代替プロセスを提案することを検討している場合は、その目標がこれを反映していることを確認してください。
リリースとは、定義上、それを所有するグループを超えて公開されるものです。私たちの場合、それは製品開発リストにいる人々のグループ以外の公開を意味します。一般の人がパッケージのダウンロードを指示されている場合、そのパッケージはリリースされています。各PMCは、リリースの承認に関するASFの要件に従う必要があります。パッケージのラベル付け方法は、下記で説明する二次的な問題です。
ソフトウェアの開発とリリースの準備中に、開発者コミュニティがテスト目的で使用できるさまざまなパッケージが提供されます。開発者以外の人がナイトリービルド、スナップショット、リリース候補、またはその他の同様のパッケージをダウンロードして使用することを促す可能性のあるリンクをプロジェクトのWebサイトに含めないでください。そのようなパッケージについて知っておくべき人は、開発リストをフォローしている人（またはそのアーカイブを検索している人）だけであり、パッケージに課せられた条件を認識している人だけです。一般の人がそのようなテストパッケージをダウンロードしていることがわかった場合は、削除してください。
いかなる状況下でも、承認されていないビルドはリリースの代替物ではありません。このポリシーが不便に思える場合は、より頻繁にリリースしてください。適切なリリース管理は、Apacheソフトウェア開発の重要な側面です。
Apache Software Foundationはオープンソースソフトウェアを制作しています。すべてのリリースは、リリースされているソフトウェアに変更を加えるために必要なソースマテリアルの形式です。場合によっては、コンパイル済みバージョンのソースをビルドするのに適切なツールを持っていない可能性のあるユーザーのために、バイナリ/バイトコードパッケージも便宜的に作成されます。このような場合、バイナリ/バイトコードパッケージはソースリリースと同じバージョン番号を持ち、ソースコードリリースのコンパイルの結果であるバイナリ/バイトコードファイルのみを追加できます。
テストパッケージはApacheリリースではありません。すべてのリリースには、適切な手続きと公式な承認が必要です。テストパッケージは進行中の開発をテストするためのものであり、プロジェクトの開発リストでのみ議論されるべきです。
ナイトリービルドは、通常1日に1回、Subversion/Gitのtrunk/ブランチからビルドされたものです。これらのパッケージは、ビルドプロセスの定期的なテストと、自動化されたテスターに回帰テスト用の共通のビルドを提供することを目的としています。一般の人が使用する目的ではありません。
リリース候補は、リリースとして承認のために提案されたが、まだプロジェクトによって承認されていないパッケージです。これらのパッケージは、開発者（および開発に関する議論をフォローしているユーザー）がテストし、以前のリリースと比較したパッケージの品質に関する意見をプロジェクトに報告することを目的としています。リリース承認の前に、多くのリリース候補が考えられます。開発テストに関心のないユーザーは、リリースが正式に承認されるまで待つ必要があります。
リリースは、一般公開用に承認されたパッケージであり、その認識されている品質または変更の可能性に関する様々な程度の注意書きが付けられています。開発者以外による日常的な使用を目的としたリリースは、通常「安定版」または「一般提供（GA）」リリースと呼ばれます。テスターやプロジェクト外の開発者によって使用可能であると考えられるが、機能または機能の点でまだ安定していない可能性のあるリリースは、通常「ベータ版」または「不安定版」と呼ばれます。プロジェクト外の最先端の開発者のみを対象としたプロジェクトの節目となるリリースは、「アルファ版」と呼ばれます。
リリースは、コンテンツがプロジェクトの配布ディレクトリ（`downloads.apache.org` のサブディレクトリ）にあるまで「リリース」されません。配布ディレクトリに加えて、Mavenまたは関連するビルドツールを使用するプロジェクトは、場合によっては、いくつかの便利なバイナリと共に`repository.apache.org`にリリースを配置します。配布ディレクトリは必須であり、リポジトリシステムはオプションの便宜的なものです。
すべてのASFリリースには、ユーザーが適切なプラットフォームとツールにアクセスしていれば、リリースをビルドしてテストするのに十分なソースパッケージが含まれている**必要があります**。ソースパッケージは、リリースマネージャーによって分離された署名で暗号的に署名されている必要があります。そのパッケージとその署名は、リリースの投票+1の前にテストする必要があります。リリースに+1票を投じる人は、リリース前に分離された署名ファイルに連結する独自の暗号署名を提供できます（リリースマネージャーの裁量による）。
PMCは、`downloads.apache.org` のサブディレクトリである配布ディレクトリ内のすべての成果物に対して責任を負います。また、ディレクトリに配置されたすべての成果物は、コミッター、できればPMCメンバーによって署名されている必要があります。また、PMCは、ソースパッケージがリリースに関連付けられたバイナリ成果物をビルドするのに十分であることを確認する必要があります。
すべてのASFリリースは、ASFライセンスポリシーに**準拠**する**必要があります**。この要件は非常に重要であり、完全なリリースを作成する前に監査を行う必要があります。特に、配布されるすべての成果物には、適切に ライセンスされたコードのみが含まれている必要があります。詳細については、FoundationのWebサイトとリリースライセンスに関するFAQを参照してください。
リリース投票は、リリース承認セクションで上記のように行われます。
+1票を投じる前に、PMCメンバーは署名されたソースコードパッケージをダウンロードし、提供されたとおりにコンパイルし、独自のプラットフォームで生成された実行可能ファイルをテストし、パッケージがリリースに関するASFポリシーの要件を満たしていることを検証する必要があります。
新しいリリースをアップロードしてから少なくとも1時間待ってから、プロジェクトのダウンロードページを更新し、発表メールを送信してください。
新しいリリースの可用性について人々に知らせることが重要です。発表には、ソースの関連するダウンロードページへのリンクを含める必要があります。少なくとも、すべての適切なメーリングリストにこのことを知らせるメールを送信する必要があります。多くのトップレベルプロジェクトには、この目的の発表リストがあります。ASF全体の発表リストもあり、適しています。
「apache.org」メールアドレスを使用せずにASF全体の発表リストに投稿することはできないことに注意してください。また、プロジェクトの概要を3〜5行記述してください（announce.AT.apache.DOT.orgリストの購読者のほとんどは、XXプロジェクトが何であるかを知らない可能性があるためです）。
SHA-1 OpenPGP互換の署名を発表メールに追加することをお勧めします。公開キーが有名なpgpサイト（例：http://pgp.mit.edu/）に既にアップロードされていることを確認してください。このキーは、リリースに署名するために使用されたキー、またはそのキーによってクロス署名されたキーのいずれかである必要があります。
インキュベーターのリリース管理ガイド（ドラフト）を参照してください。または、既存のApacheプロジェクトの「リリース方法」に関する開発者ドキュメントを参照してください。（著者は、このプロジェクトのこのドキュメントに精通しています）。
厳密に言えば、リリースはコミッターが所有および管理するハードウェアで検証する必要があります。つまり、コミッターが物理的に所有および管理し、排他的に完全な管理者/スーパーユーザーアクセス権を持っているハードウェアです。それは、そのようなハードウェアだけがPGP秘密キーを保持する資格があり、リリースは秘密キーが存在するマシンまたはそれと同等の信頼できるマシンで検証される必要があるためです。
実際には、リリースがソース管理タグのアーカイブ（tarballやzipファイルなど）を超えるものから構成されている場合、そのアーカイブを検証する実際的な方法は、ローカルでビルドすることだけです。生成されたファイル（特にバイナリファイル）を手動で検査することは現実的ではありません。したがって、基本的に「はい」です。
注：この回答は、ソース管理タグからリリース成果物を生成するために使用されるプロセスを参照しています。この成果物の技術的な品質をテストすることには言及していません。
テストパッケージは、同意した開発者と関心のあるコミュニティメンバーのみが使用するため、エンドユーザー向けのページでホストまたはリンクしたり、`closer.lua`スクリプトを使用してリリースしたりするべきではありません。
プロジェクトは、`dist`リポジトリの`/dev`ツリーまたはrepository.apache.orgのステージング機能を使用して、開発者テスト/投票のために投稿されたリリース候補をホストする必要があります（正式にGAリリースとして承認される前）。
リリース候補ではないナイトリービルドは、ci.apache.orgプロジェクトエリアでホストできます。INFRAチケットを提出するだけです。
現在のリリースは、`https://downloads.apache.org/`の下に配置することにより、ASFコンテンツ配布システムから提供する必要があります（リリースをアップロードするには？を参照）。
プロジェクトのダウンロードページは、`closer.lua`スクリプトを使用する必要があり、メインのApache Webサイトに直接リンクしてはなりません。詳細については、ダウンロードページの作成手順を参照してください。ソフトウェアのWebサイトドキュメントには、ソースのダウンロードページへのリンクが含まれている必要があります。
プロジェクトWebサイト（`http://{project}.apache.org`）、VM（`http://{project}.zones.apache.org`および`http://{project}-vm.apache.org`）、およびソースコード管理リポジトリ（`svn.apache.org`とGitリポジトリ）を使用してリリースを配布することはできません。つまり、それらからリリースをダウンロードすることはできません。
すべてのリリースはhttp://archive.apache.org/dist/にアーカイブされます。
自動化されたプロセスにより、リリースが最初にhttps://downloads.apache.org/に表示されてから約1日後にアーカイブに追加されます。リリースが`https://downloads.apache.org/`に配置されると、`http://archive.apache.org/dist/`に自動的にコピーされ、`https://downloads.apache.org/`から削除された後も永久的に保存されます。
アーカイブされていない（レガシー？）リリースがある場合は、インフラストラクチャに`http://archive.apache.org/dist/`へのコピーを依頼してください。
`downloads.apache.org`には、現在開発中の各ブランチの最新のリリースを含める必要があります。バージョンブランチの開発が終了したら、そのブランチのリリースをプロジェクトのダウンロードディレクトリから削除する必要があります。
（プロジェクトがsvnpubsubを使用している場合は、`https://dist.apache.org/repos/dist/release/
例えば、Apache Foo 1.2.xがFoo 1.1.aと同じラインの新しいリリースである場合、1.2.xがリリースされた際に1.1.aは削除する必要があります。古いリリースをアーカイブに移動する方法を参照して、すべてのリリースが自動的にアーカイブされることに注意してください。
Apache Foo 1.2が新しいブランチであり、1.1で並行して開発が継続される場合、/distから1.1.aと1.2.xの両方を提供することは許容されます。
リリース用のtarballを、https://dist.apache.org/repos/dist/release/リポジトリの適切なサブディレクトリ（つまり、TLP名）にコミットします。私たちの同期プロセスは、15分以内にファイルをマスターダウンロードサイトにプッシュします。
新しいリリースをアップロードした後、プロジェクトのダウンロードページを更新する前に約1時間待ちます。
リポジトリディレクトリhttps://dist.apache.org/repos/dist/release/<TLP name>/は、**正式リリースのみ**用です。つまり、PMCによって承認されたアーカイブ（+署名、ハッシュ）です。このため、**デフォルトでは、PMCメンバーのみがdist/releaseディレクトリツリーを更新できます**。
リリースマネージャーがPMCのメンバーでない場合は、PMCメンバーに実際のリリース公開を依頼する必要があります。
PMCは、PMCメンバー以外のユーザーがdist/releaseエリアを更新できるように投票することもできます。これを設定するには、PMCの投票を参照して、INFRA JIRAでJIRAチケットを作成してください。
https://dist.apache.org/repos/dist/dev/<TLP name>/の下に開発エリアもあります。これは、開発リリースに使用できます。例えば、スナップショットやリリース候補をここに保存できます。重要な点として、このディレクトリはsvnpubsubを介してコンテンツ配信システムに公開されません。正式リリースの準備段階のステージング場所として機能することを意図しています。
プロジェクトのすべてのコミッターは、プロジェクトのdist/devエリアに書き込むことができます。
リリース候補に使用する場合、投票が成功した後、適切なファイルをdev/ツリーからrelease/ツリーに移動して公開できます。
dist/リポジトリへのコミットメールは、通常のプロジェクトメーリングリストに送信されます。
ほとんどのプロジェクトは、前の2つの質問で説明されているようにリリースを配布できます。ただし、コンテンツ配信リソースに負担をかける可能性のあるリリースは、**必ず**インフラストラクチャと調整する必要があります。
**注記** インフラでは、リリースアーティファクトのサイズを100MB以下に保つことを推奨しています。ASFは、1GBを超えるリリースアーティファクトを**ホストしません**。
他の配布ポリシー（コンテンツ配信システムを介して配布できるもの、または配布しなければならないものなど）からの特定の免除も、インフラストラクチャと調整する必要があります。
| 種類 | 場所 |
|---|---|
| ナイトリービルド | ci.apache.org/projects |
| 現在のリリース | downloads.apache.org |
| 古いリリース | archive.apache.org/dist |
downloads.apache.orgは自動的にアーカイブされます。したがって、正式リリースのコピーは既にアーカイブに存在します。リリースをアーカイブに移動するには、プロジェクトのdistディレクトリにあるコピーを削除するだけです。ダウンロードページからのリンクを更新することを忘れないでください。
Mavenリリースの公開に関するガイドを参照してください。
Apache License, Version 2.0の適用をお読みになり、最新の情報をApacheライセンスとApache Legalのページでご確認ください。
すべてのソースファイルには、適切なASFライセンステキストを含める必要があります。
簡単に言うと、配布ごとにライセンスのコピーは1つだけ必要です。この完全なライセンスファイルは、LICENSEという名前のファイルで配布のルートに配置する必要があります。ASFで開発されたソフトウェアの場合、各ソースファイルには標準的な通知を含めるだけで済みます。
新しいライセンスでは、そのような帰属通知（Apache帰属通知を含む）を含むNOTICEファイルを使用できます。こちらをお読みください。
既存のソースファイルに含まれる帰属通知は、NOTICEファイルに移動する必要があります。NOTICEファイルは、LICENSEファイルの隣に配布物に含める必要があります。
作成された新しいNOTICEファイルには、標準的なASF帰属通知が含まれていることを確認してください。
こちらをお読みください。
製品のソフトウェアライセンスで要求される必須情報のみ。通常のドキュメントには適していません。
はい！NOTICEファイルには、以下に示す標準的なASF帰属を含める必要があります。
This product includes software developed at
The Apache Software Foundation (/).
注記：2013年1月30日以前（r1440650）のバージョンのこのドキュメントは、「開発者によって」というフレーズを「開発者によって」の代わりに使用していたため、間違っていました。公式な表現は、2006年5月24日の理事会議事録のセクション6Cで確立されました。
アーティファクトに複数のライセンスに基づくコードが含まれている場合、LICENSEファイルにはこれらのライセンスすべての詳細を含める必要があります。Apacheライセンスではないコンポーネントごとに、コンポーネントの詳細をLICENSEファイルに追加する必要があります。コンポーネントライセンス自体を追加することも、ライセンスが長い場合など、LICENSEファイルから参照できるアーティファクトの別の場所に保存することもできます。
こちらに追加されたライセンスを示す例があります。
ASFリリースには、通常、ソースパッケージと一緒に追加の資料が含まれています。この資料には、リリースに関するドキュメントが含まれている場合がありますが、LICENSEファイルとNOTICEファイルを含める必要があります。前述のように、これらのアーティファクトは、プロジェクトの配布ディレクトリに配置する場合は、コミッターによって分離された署名で署名する必要があります。
繰り返しますが、これらのアーティファクトは、LICENSEファイルとNOTICEファイルが含まれている場合にのみ配布できます。たとえば、Javaアーティファクト形式は圧縮されたディレクトリ構造に基づいており、jarを配布したいプロジェクトは、jar内のMETA-INFディレクトリにLICENSEファイルとNOTICEファイルを入れる必要があります。
このセクションのいかなる内容も、すべてのリリースが主に署名されたソースパッケージに基づいている必要があるというこことここで定義されている要件に優先するものではありません。
ダウンロード統計ページをご覧ください。