このページを改善する

新規バージョンのリリース

このガイドはメンテナ向けです。 これらの特別な人々は、Jekyllのリポジトリの1つ以上に書き込み権限を持ち、他者の貢献のマージを支援します。ここに書かれている内容は興味深いものかもしれませんが、すべての人向けではありません。

リリースを行う前に理解しておくべき最も重要なことは、緊張する必要がないということです。ほとんどの操作は元に戻すことができ、たとえ不完全なgemバージョンを公開してしまっても、そのバージョンをスキップできます。不確実な点や次に何をすべきかわからない場合は、他のメンテナに連絡することをためらわないでください。

バージョンの更新

手動でバージョンを更新する必要がある唯一の重要な場所は、lib/jekyll/version.rbです。これを調整すれば、他のすべては問題なく動作するはずです。

バージョンは主に"major.minor.patch"の形式になります。場合によっては、"major.minor.patch.suffix"の形式のプレリリース版をリリースすることもあります。suffixは標準化されておらず、pre.alpha1、pre.rc2、または単にbeta3など、何でもかまいません。

正しいバージョンを判断するには、まず履歴ドキュメントHistory.markdownの## HEADセクションを参照してください。

  • Major Enhancementsという見出しのサブセクションがある場合
    • バージョン文字列のmajorコンポーネントを増分し、minorとpatchコンポーネントを0にリセットします。
    • 該当する場合はsuffixを追加します。
    • たとえば、"3.9.1" => "4.0.0"または"3.9.1 => "4.0.0.alpha1"。
    • リリースプロセスの次のステップにスキップします。
  • Minor Enhancementsという見出しのサブセクションがある場合
    • minorコンポーネントのみを増分し、patchコンポーネントを0にリセットします。
    • 該当する場合はsuffixを追加します。
    • たとえば、"4.0.2" => "4.1.0"または"4.1.0" => "4.2.0.pre"。
    • リリースプロセスの次のステップにスキップします。
  • その他の場合は、patchコンポーネントまたはsuffixコンポーネントを適宜増分します。たとえば、"4.0.2" => "4.0.3"または"4.1.0.beta3" => "4.1.0.rc"。

リリース記事の作成

まだ作成していない場合は、付属のrakeコマンドを使用して、新しいリリース記事のスキャフォールドを生成できます。

bundle exec rake site:releases:new[3.8.0]

ここで3.8.0は新しいバージョンに置き換える必要があります。

次に、記事を作成します。前回のリリース以降に貢献してくれたすべての協力者とメンテナに感謝することを忘れないでください。次のコマンドを使用して、彼らの名前のログを生成できます。

git shortlog -sn master...v3.7.2

ここでv3.7.2は前回のリリースのgitタグです。タグがリポジトリに存在しない場合は、次を実行します。

git pull

完了したら、リリース記事のプルリクエストを作成してください。

履歴ドキュメントの更新

History.markdownの最初のヘッダーをバージョンマイルストーンに置き換えます。次のようになります。

- ## HEAD
+ ## 3.7.1 / 2018-01-25

バージョン番号と日付を調整します。## HEADヘッダーは、次回プルリクエストがマージされたときに再生成されます。

以下に示すように、優先順位が低い順にサブセクション（全体として）を並べ替えます。

## 4.2.0 / 2020-12-14

### Major Enhancements

...

### Minor Enhancements

...

### Bug Fixes

...

### Security Fixes

...

### Optimization Fixes

...

### Development Fixes

...

### Site Enhancements

...

これが完了したら、次のコマンドを実行してウェブサイトを更新します。

bundle exec rake site:generate

これにより、ウェブサイトの変更ログが更新され、さまざまな場所でバージョンがプッシュされます。

History.markdownファイルをスペルミスなどがないか、もう1度手動で確認することをお勧めします。それらを手動で修正し、ウェブサイトの変更ログを生成した後、変更をコミットしてください。

バージョンのプッシュ

このステップを実行する前に、次のことを確認してください。

  • リリース記事が準備されており、理想的には以前のプルリクエストを介して既に公開されています。
  • 以前のすべてのステップが完了しており、特にlib/jekyll/version.rbへの変更がコミットのためにステージングされています。
  • ローカルのmasterブランチにステージングされた変更をコミットします。コミットメッセージは"Release :gem: v[CURRENT_VERSION]"が望ましいです。

残っているのは、このコマンドを実行することだけです。

git push upstream master

ここでupstreamはgit@github.com:jekyll/jekyll.gitを参照します。

これにより、新しいgemを自動的にビルドし、リリースコミットにタグを付け、タグをGitHubにプッシュし、最後に新しいgemをRubyGemsにプッシュするGitHub Actionsワークフローがトリガーされます。GitHubリリースの作成も心配する必要はありません。@jekyllbotが、リリースワークフローが新しいタグを公開するときにそれを処理します。

そして、ワークフローが正常に完了したら、完了です！ :tada: お祝いしましょう！

@jekyllrbのTwitterアカウントへのアクセス権がある場合は、そこからリリース記事をツイートする必要があります。アクセス権がない場合は、別のメンテナに依頼するか、アクセス権を付与してもらってください。

ドキュメントのビルド

オフラインで使用するために、ドキュメントを:gem: Gemとしてパッケージ化します。

これはjekyll-docsリポジトリを使用して行われ、より詳細な手順がそこに記載されています。

コア以外のgemの場合

jekyll/jekyllのメンテナではない場合、多くの場合、手順ははるかに簡単です。一般的に、手順は次のようになります。

  • 通常lib//version.rbでgemバージョンを手動で更新します。
  • 履歴ファイルを調整します。
  • デフォルトブランチに変更をコミットします。コミットメッセージは"Release :gem: v[CURRENT_VERSION]"が望ましいです。
  • リモートリポジトリにプッシュします。
  • 喜びましょう

不明な点があれば、プロジェクトのメンテナに質問してください！