リリースサイクルとバージョンタグ

[kazzyfrog]

バージョンの付け方というか、刻み方に関する相談です！

今まで通りmainブランチ＋作業用ブランチでいく方向であれば、
リリースサイクルとバージョンタグに関しては、
以下のような形がいいかも？と考えたのでメモしておきます！

• ▶︎n.9：機能追加は一旦終えて、仕様の確認作業や修正を行う
• →n.0：リリース & 機能追加はせず、仕様には変更がないコードやサイトの設定系の改善を行う
• →n.1：次のバージョンのリリースに向けて機能実装
• →n.9：・・・

上記でいくと、現在は、v0.9！
リリースしたら、v1.0.0
リファクタリング系終わったらv1.1.0
次のリリースまでの機能実装して、v1.9.0

つまり、マイナーバージョン（v1.2.3の2。真ん中の数字）は、
9 or 0 or 1 で、リリース前、リリース後、機能実装を判別する的な！？

[kazzyfrog]

GitHubの、リリースノート作成画面での説明：

Tagging suggestions
It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0.0 or v2.3.4.

If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release versions might be v0.2.0-alpha or v5.9-beta.3.

Semantic versioning
If you’re new to releasing software, we highly recommend to learn more about semantic versioning.

A newly published release will automatically be labeled as the latest release for this repository.

If 'Set as the latest release' is unchecked, the latest release will be determined by higher semantic version and creation date. Learn more about release settings.

[kazzyfrog]

訳：
タグ付けの提案
バージョン名の前に文字vを付けるのが一般的です。いくつかの良いタグ名は、v1.0.0またはv2.3.4かもしれません。

タグが本番使用用でない場合は、バージョン名の後にプレリリース版を追加します。いくつかの良いプレリリースバージョンは、v0.2.0-alphaまたはv5.9-beta.3かもしれません。

セマンティックバージョニング

ソフトウェアのリリースが初めての場合は、セマンティックバージョニングについて詳しく学ぶことを強くお勧めします。
新しく公開されたリリースは、このリポジトリの最新リリースとして自動的にラベル付けされます。

「最新のリリースとして設定」がチェックされていない場合、最新のリリースはより高いセマンティックバージョンと作成日によって決定されます。リリース設定の詳細をご覧ください。

[kazzyfrog]

#163 に、以下のように書きました！

GitHubでは、プルリクの内容に応じて、リリースノートを自動生成する機能などもあります！

作成した、バージョンタグと、リリースノートは、すぐに消したり編集したりできます！

なので、一旦練習で、
v0.9のバージョンタグとリリースノートを、作成（自動生成）してみた方がわかりやすいですかね？

[kazzyfrog]

その場合、手順のスクショも撮るつもりです！

[kagomen]

早速ありがとうございます！
自分のリポジトリで練習してみて、なんとなく流れを把握しました。

一旦練習で、
v0.9のバージョンタグとリリースノートを、作成（自動生成）してみた方がわかりやすいですかね？

ですね！
実際どんな感じで反映されるか見たいです。！

あとはyamlファイルでラベル別に分類できるみたいですが……
個人的には流れが追いづらくなりそうだから必要ないかなーという気もしますが、どうなんでしょうか👀

[pss-aileen]

すみません、全然理解できていないので
まともに議論できないのですが
私の脳みそはこんな感じでやると良いのかな...？と考えています。

簡単に言うと、リリース前はbetaとして、本リリース？ローンチの時にbetaをはずす感じはどうかな...と

version	内容
v0.0.0 or v1.0.0-beta	今
v1.0.0	リリース
v1.0.1	誤字やドキュメントなど軽微な修正
v1.1.0	内部的なリファクタリング？ある程度のもの
v1.1.1	誤字やドキュメントなど軽微な修正
v2.0.0-beta	バージョン2の実装
v2.0.0	バージョン2 リリース
v2.0.1	修正第1弾
v2.0.2	修正第2弾
v2.0.3	修正第3弾...
v2.1.0	themeの追加（例！！）

参考

• 正しいバージョンの付け方を身につけよう | 株式会社LYZON
• セマンティックバージョニングによるバージョン表記方法
• セマンティック バージョニング 2.0.0 |セマンティック バージョニング
• ソフトウェアのバージョンと開発スタイルの関係について | フューチャー技術ブログ

[kazzyfrog]

ほぼほぼ同じ認識です！

自分が書いたのは、
betaを、１つ前バージョンのバージョンのマイナーを「9」で表すことで、
もうすぐメジャーバージョンの数字が上がる！的なことを、見ただけで簡単に表したかっただけなので、
「v2.0.0-beta」の形でも、全然良いと思います！

リリース前を、「v2.0.0-beta」とするか、「v1.9.0」とするか、という違いですね！

[kazzyfrog]

https://github.com/first-contributions-ja/first-contributions-ja.github.io/releases

試しに練習で、
v0.9のバージョンタグとリリースノートを、作成（自動生成）してみました！
あとで消したり編集したりもできます！👍

特に自分で変更したりすることなく、自動生成のままです！
プルリクのタイトルが全部入っている感じ！

[kazzyfrog]

リリースノートをラベル（カテゴリー）別で分ける際は、
〜〜〜
OGPのバグ修正をfixにしてしまうと、OGPの設定は設定関連に記載されるのに、バグ修正はコード関連に記載されたりして、機能追加や修正の流れが追いづらくなるのでは？と考えていました。

確かに、その場合、バグ修正はコード関連に記載されて、少しわかりづらくなりますね！！

choreやstyleの壁を超えるくらいの、カテゴリーとしての支配力（？）がfixにはあるんでしょうか❓

個人的には、
「機能追加と、バグ修正と、それ以外の変更（それぞれに適したラベル）」というくらいの感覚だったので、
仕様と違うこと・想定していないことの修正（「修正すべき」というより、「修正しないといけない」こと）は、
設定系であれスタイルであれ、fixを使うべきかなという認識でした！
（これは完全に個人の見解というか、認識的なことなので、違う方法で統一してもOKです！）

それと、リリースノートをラベル（カテゴリー）別で分ける際は、
prefixのラベルは全部並列で、下記のような形でいいのでは？と思いました！
（コード全般でまとめる必要はないかも？と思った次第です。。！！）
参考までに！

---

What's Changed

✨ New Features

• A追加

🐛 Bug Fix

• Bの不具合を修正

📚 Documentation

• C追記

🎨 Style

• スタイルDの適用

♻️ Refactoring

• Eをコンポーネントに分割

🔧 Chore

• Fの導入

Other Changes

• その他

[kagomen]

「機能追加と、バグ修正と、それ以外の変更（それぞれに適したラベル）」というくらいの感覚だった

なるほど！ということは、条件分岐の仕方として、まず

機能追加か？バグ修正か？それ以外か？

があって、次に

スタイル関連か？設定関連か？ドキュメント関連か？

があるんですね！（合ってますか？）

変更の流れを追うことを優先させるのであれば、
スタイルはバグ修正も変更も全部styleに、とした方が良いかなと思いますが、

機能追加やバグ修正の告知を優先させるのであれば

prefixのラベルは全部並列

が適してるなと思いました！

メンテナー視点で（というか、リリースノートというものに対して）、変更の流れを追うことを第一優先に考えてましたが、ユーザー視点に立つと、割とそんな変更の流れはどうでもよくて、機能追加やバグ修正の告知の方が大事かも！と思いました。

ならば、今のprefix（＋ refactor を追加？ ）のままでも問題ないな、と！

[kazzyfrog]

（合ってますか？）

おっしゃる通りです！
個人的には、機能追加とバグ修正が、他よりかは重要度が１つ高いような感覚でした！！

ユーザー視点に立つと、割とそんな変更の流れはどうでもよくて、機能追加やバグ修正の告知の方が大事かも！と思いました。

そうですね！！
そもそも、リリースノート自体、何十回も継続的にリリースされていくようなアプリやライブラリなどが前提で、
「このバージョンリリースで、こういう機能が追加されて、こういうバグが解消されたんだ〜〜！」
って感じの記録というか告知だと思うので、リリースノート内での流れはそんなに重要じゃないかな？と思ってます！

リリースごとの流れを記録する役割が強いのかな、と思ってます！👍

[kazzyfrog]

問題なければ、 上の例に掲載したような形で、
一度.github/release.yml ファイルを作成してみますよ！

それをみて、以下など？を確認・検討してみてもいいかもです！

• styleやrefactorは必要か
• fixとbugFixの方が良いか
• コード関連と、その他でまとめた方がいいか
• 過去のPRのラベル付けが適切か

[kagomen]

はい！大丈夫だと思います！
ありがとうございます……！🙏✨

それをみて、以下など？を確認・検討してみてもいいかもです！

了解です！！

[kazzyfrog]

メモ：
このスレッドに関しては、以下を決めれば、イシュー( #163 )片付きそうです！

• バージョンタグの付け方（リリース前を、「v2.0.0-beta」とするか、「v1.9.0」とするか）
• バージョンは、v1.0.0のリリースから付け始めるか、現在（「v1.0.0-beta」or「v0.9.0」）から付けるか
• リリースノートは、この通り自動生成だと全部並列なので、カスタマイズするかどうか。

[kazzyfrog]

あ、でもせっかくなら、リリースノートのカスタマイズもやってみた方がいいかもです
Githubの色々を使い倒すのも１つのテーマ？なので！

[pss-aileen]

• v0.9.0よりかは、v1.0.0-betaのほうが、一般的に？わかりやすいかな？と思ったので、v1.0.0-betaが良いかなと思いました !
• リリースノートのカスタマイズはちょっと時間がないので手が出せませんが分別できると良いな〜と思いました！

[kazzyfrog]

そしたら以下で良さそうですかね？

• バージョンタグの付け方は、この通り
  • リリース前を「v1.0.0-beta」：機能追加は一旦終えて、仕様の確認作業や修正を行っている
  • リリース後は「v1.0.0」： リリースして、機能追加はせず、仕様には変更がないコードやサイトの設定系の改善を行っている
  • 機能の実装は「v1.1.0」：次のバージョンのリリースに向けて機能実装している
  • バグの修正などは、適宜パッチ（v1.2.3の3。１番右の数字）を上げていく
• バージョンは、現在の「v1.0.0-beta」から付け始める
• リリースノートは、上記のprefixのスレッドでの内容で、カスタマイズする！
  • カスタマイズは、プルリクについたラベルに基づいて、自動で生成できるようになる：参考：GitHub のリリースノート自動生成機能を使う
  • 現状は、その通りにprefixをつけられていないので、手書きで見出しをつけて編集する！（もしくは、過去のPR全部にラベルつける？→半分くらい変更なさそうなのはつけた！）
  • 確かこれ、Github Actionsとかで、PRに自動でラベルつけることできたはず。。

[kazzyfrog]

バージョンは、現在の「v1.0.0-beta」から付け始める

と思ったのですが、
v1.0.0-beta（ドッグフーディングを行なった）時点では、
.github/release.yml ファイルが作成されていないので、自動生成リリースノートをラベル毎に分けて生成することができませんでした！
全部がカテゴリラベルなしで、並んでいる状態、、。

4/6、 #167 にて、
.github/release.yml ファイルを作成したので、このコミット以降であれば、
自動生成リリースノートをラベル毎に分けて生成することができます！

なので、「v1.0.0」からのリリースでいいかもと思いました！
（それであれば、.github/release.yml ファイルのコミットも含まれるので、問題なくラベル毎に生成できます！）

[kazzyfrog]

問題なければ、
「v1.0.0-beta」のタグを削除して、「v1.0.0」を最初のタグとして作成します！！

---

（追記）
「v1.0.0-beta」のタグは削除しなくても、「v1.0.0-beta」のリリースノートを作成しなければ、タグ自体は残せました！

まとめ：

• v1.0.0-beta（ドッグフーディングを行なった）時点の、バージョンタグは残せるので残す
• v1.0.0-beta時点では、リリースノートのカスタマイズ（ラベル毎に分けて自動生成する）が適用されないので、リリースノートは生成しない
• v1.0.0では、リリースノートのカスタマイズ（ラベル毎に分けて自動生成する）が適用されるので、リリースノートを生成する！

[kazzyfrog]

バージョンタグとリリースノートの作成手順

[kazzyfrog]

2-4. 必要があれば、下の２つの項目にチェックを入れて、「Publish release」をクリックする！

• 「Set as a pre-release」は、α版やβ版のリリースの際に使う。チェックされていると、リリースノートに「pre-release」と表示される！
• 「Create a discussion for this release」がチェックされていると、このリリースノートについての、ディスカッションのスレッドを立てることができる！（ディスカッションのカテゴリを指定できる）

[kazzyfrog]

生成されたリリースノートがこちら：
https://github.com/first-contributions-ja/first-contributions-ja.github.io/releases

バージョンの横に、Pre-releaseと表示されている！

右下に、このリリースに関する、ディスカッションのスレッドへのリンクが貼られる！
→ #168

[kazzyfrog]

テスト終了！！⏰

[kazzyfrog]

ちなみに、バージョンタグがあれば、その時点でのソースコードを見ることができる！
リリースノートは、あくまでそのバージョンでの、内容をまとめて周知するためのノート！
（現時点では、タグは「v1.0.0-beta」「v1.0.0」の２つあるが、リリースノートは「v1.0.0」だけ）

[kagomen]

ありがとうございます！！！
ひとまずwikiにurl貼り付けるだけ貼り付けておきました！