コントリビューション・ガイドライン

==================

概要

オープンソースプロジェクトのため、次の点を尊重するなら誰もが貢献できます :

  • コードを投稿する前に、著者はすべてのテストが確実に行われるようにする必要があります。下記のテストの起動方法を参照してください
  • 開発されたコードは、linters によって強制される構文ガイドラインに従わなければなりません
  • コードは、以下に定義する分岐モデルと変更ログのポリシーに従って開発する必要があります
  • 新しい機能が追加された場合は、既に作成されたサンプルの例に従って、ユニットテストを提供する必要があります

コントリビューションを開始するには :

1.リポジトリをフォークするには、ページの右上にある "Fork" ボタンをクリックします。
2.フォークされたリポジトリをクローン :

git clone https://github.com/your-github-username/lightweightm2m-iotagent.git
3. lightweightm2m-IoT Agent のメインのリポジトリをリモートとしてリポジトリに追加すると、リモート・リポジトリの名前を使用できますが、lightweightm2m-IoT Agent である必要はありません。次の手順で使用します : 
git remote add lightweightm2m-iotagent https://github.com/telefonicaid/lightweightm2m-iotagent.git

コントリビューションを開始する前に、フォークされたリポジトリ内の develop ブランチと、lightweightm2m-IoT Agent メインリポジトリ内の develop ブランチを、この手順に従って同期させてください。

1. 開発ブランチにいない場合に備えて、ローカルの develop ブランチに変更します :

  git checkout develop
2. リモートの変更を取得します :
  git fetch lightweightm2m-iotagent
3. それらをマージします : 
  git rebase lightweightm2m-iotagent/develop

このガイドラインに従ったコントリビューションは develop ブランチに追加され、次のバージョンでリリースされます。リリース・プロセスについては、下記のリリースのセクションで説明しています。

ブランチ・モデル

リポジトリには2つの特別なブランチがあります :

  • master : プロジェクトの最後の安定版のコードを保持します。新しいバージョンがリリースされたときにのみ更新され、常に develop の最新の状態で更新されます
  • develop : 最後の安定した開発コードが含まれています。新機能とバグ修正は常に develop にマージされます

新しい機能やリファクタリングの開発を開始するには、task/<taskName> の名前を持つ新しいブランチを作成する必要があります。このブランチは、develop ブランチの現在のバージョンから作成する必要があります。新しい機能が完了すると、develop に機能分岐からプルリクエストが作成されます。プルリクエストを作成する前に、linters とテストの両方をチェックすることを忘れないでください。

バグ修正は、bug/<bugName> と呼ばれるブランチ名を除いて、他のタスクと同じように機能します。

リポジトリに貢献するためには、これらの同じスキームを分岐したリポジトリに複製する必要があります。そのため、新しい機能や修正は、すべて develop の最新のバージョンから取得して、develop に再度マージする必要があります。

すべての task/* と bug/* ブランチは一時的なものなので、マージされたら削除する必要があります。

release/<versionNumber> という別の一連のブランチがあり、製品の各バージョンごとに1つあります。この分岐は、プロジェクトのリリースされた各バージョンを指し、永続的でリリースごとに作成されます。

チェンジ・ログ

プロジェクトには、プロジェクトのルートにある CHANGES_NEXT_RELEASE というバージョンの変更履歴が含まれています。新しい機能やバグフィックスが develop にマージされるたびに、この変更ログに新しいエントリを追加する必要があります。新しいエントリには、解決している問題のリファレンス番号(存在する場合)が含まれているはずです。

新しいバージョンがリリースされると、変更履歴がクリアされ、そのバージョンの最後のコミット時に修正されたままになります。変更履歴の内容は、Github release のリリースの説明にも移動されます。

リリース

リリースを行うプロセスは、次の手順で構成されます :

1. 新しいタスクブランチを作成して、sufix-next を持つ、package.json内の開発バージョン番号を、sufix なしの新しいターゲットバージョンに変更し、PRを develop に変更します
2. バージョン番号で指定された develop の最終バージョンからタグを作成し、それをリポジトリにプッシュします
3. 作成したタグから Github でリリースを作成します。 この説明では、変更履歴の内容を追加します
4. バージョン番号で指定された develop の最終バージョンからリリース・ブランチを作成します
5. develop を master に PR
6. 次のリリースを準備するための新しいタスクを作成し、現在のバージョン番号にサフィックス -next を追加して、これを開発バージョンとして通知します