Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

バージョン付与の統一 #12

Closed
windyakin opened this issue Dec 21, 2015 · 11 comments
Closed

バージョン付与の統一 #12

windyakin opened this issue Dec 21, 2015 · 11 comments

Comments

@windyakin
Copy link
Owner

現在HonokaとそのForkテーマ間でバージョンの付与方式が三者三様であるので、エンドユーザにも理解しやすくするため統一したい。

現状

現状は以下の通り。どれも一応セマンティックバージョニングの規約は守れているがバラバラなのが現状。

Bootstrap Honoka Umi Nico
(3.3.5) 3.3.5-d (None) 3.3.5-1.0.0
(None) (None) 3.3.5-1.0.1
3.3.6 3.3.6 3.3.6-1 3.3.6-1.1.0
3.3.6-a 3.3.6-2 3.3.6-1.1.1
3.3.6-b 3.3.6-3 3.3.6-1.1.2

Honoka

  • Bootstrapのバージョンアップ時の初版
    • Bootstrapのバージョン番号と同じ
  • Honokaの修正
    • - 区切りで a, b, c... と英字によるバージョンの増加

Umi

  • Bootstrapのバージョンアップ時の初版
    • Bootstrapのバージョン番号の後ろに - 区切りで 1 から番号を振る
  • Honokaの修正
    • - 以降の数字を増やす

Nico

  • Bootstrapのバージョンアップ時の初版
    • Bootstrapのバージョン番号の後ろにさらに独自に振ったバージョン番号のMINOR番号を上げる
  • Honokaの修正
    • 独自に振ったバージョン番号のPATCH番号を上げる(?)
  • Nico独自の修正
    • 独自に振ったバージョン番号のPATCH番号を上げる

気にしておくべき事項

  • Bowerでバージョン番号を指定しない時、最新版がインストールされるようにしたい
    • 現在のHonokaのバージョン付けであると初版の優先度が高く、以降のHonoka独自修正のバージョンは指定しないとインストールされない
  • Forkテーマ独自の修正の際にどうするか
    • Honokaに影響を与えない独自の修正(色など)をする際のバージョンの付け方
  • Forkが対応しない場合
    • Honokaの変更に付いて来れない状態でバージョン変更に抜けができた場合どうするか

参考

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

@ysakasin
Copy link
Contributor

バージョン付与の統一することには概ね賛成です。

いくつかバージョニングについていくつか提案します。私としてはUmiのバージョニングと同類のもの、もしくは提案の1つ目が良いと思っています。

Honoka familyのバージョニングはPATCHでする

MAJOR.MINORは元となるBootstrapのバージョンを流用し、PATCHでHonoka familyの独自アップデートを管理する。

時系列に沿ったアップデート内容 Honoka Umi Nico
Bootstrap 4.0.0に対応 4.0.0 4.0.0 4.0.0
Umi固有のアップデートをした - 4.0.1 -
Honoka固有のアップデートをした 4.0.1 4.0.2 (対応しない)
Bootstrap 4.0.1に対応した 4.0.2 4.0.3 4.0.1
Bootstrap 4.1.0に対応した 4.1.0 4.1.0 4.1.0

Bootstrapのバージョニングに関係なく Honoka family のバージョニングする

Umi や NicoはMAJOR.MINORについてはHonokaと同じバージョンを採用し、個別のアップデートでPATCHを変更する。

Nico likeなバージョニングをする

ただし、Bootstrapの対応バージョンを上げた場合には1.0.0に戻す

@ysakasin
Copy link
Contributor

Bootswatchのバージョニング例

  • Bootstrapのバージョンアップ時の初版
    • Bootstrapのバージョン番号と同じ
  • Bootswatchの修正
    • + 区切りで 1, 2, 3 と数字によるバージョンの増加

Bootswatch releases

@kubosho
Copy link
Contributor

kubosho commented Dec 21, 2015

結論から言うと、自分も「Honoka familyのバージョニングはPATCHでする」でいいと思います。

今のNicoのバージョニングはBootstrapのバージョンが上がった場合、独自に振ったバージョンが上がっていきます。
たとえば4.0.0に対応した場合は、おそらく4.0.0-2.0.0となります。
ただバージョンが2つ表記されて分かりにくいのと、Nico独自のバージョニングになってしまっている以上、このバージョニングは捨てる必要があると考えました。

@windyakin
Copy link
Owner Author

バージョニング形式の個人の意見としてはUmiのバージョニング形式が一番要求を満たせているかなと感じていたのですが…。

今までBootstrapとバージョン表記の互換を維持してきたのは、やはり何をベースにしているのか開発者にも利用者にもひと目にわかりやすいのが一番だったからだと思います。

あとHonoka family間のバージョン互換については、現状は基本的にバグ等があった場合にはHonokaにPull Req→Forkにmergeという流れになっているということ。またHonokaのForkテーマが独自の変更を加えるのはかなりのレアケースだと思うので、Honokaのバージョン表記に合わせる感じが一番手っ取り早いのではないでしょうか。

Bootstrap Honoka Umi Nico 備考
4.0.0 4.0.0-1 4.0.0-1 4.0.0-1 Bootstrapの4.0.0対応初版
4.0.0-2 4.0.0-2 (None) Honokaの変更
4.0.0-3 (None) 4.0.0-3 Honokaの変更
4.0.0-4 4.0.0-4 4.0.0-4 Honokaの変更
4.0.1 4.0.1-1 4.0.1-1 4.0.1-1 Bootstrapの4.0.1対応初版

@ysakasin
Copy link
Contributor

Umiのバージョニング形式をとるのは賛成です。

ただ、そのレアケースもどうにかしたいですね。今まではHonokaのアップデートに混ぜて済ませていましたが、Bootstrap 4系へのアップデートでまたforkテーマ固有のバグが発生しやすくなるのではないかと思っています。

@kubosho
Copy link
Contributor

kubosho commented Dec 23, 2015

すいません書いてなかったですが、Umiのバージョニング形式でもいいと思います。
レアケースは起きたらその時考える…でもいい気がします。

@windyakin
Copy link
Owner Author

なんとなく嫌な予感がしたので、検証してみました。

Umiは今まで全てのリリースをMAJOR.MINOR.PATCH-ORIG形式のバージョニングにしており、例えばHonokaで Bootstrap v3.3.6 対応初版の v3.3.6 についても v3.3.6-1 でリリースしています。なので Bower を使ってバージョン指定なしでインストールすると、 v.3.3.6-1 が優先的にインストールされるようになっています。これは求めている挙動です。

% bower install git@github.com:NKMR6194/Umi.git
bower not-cached    git@github.com:NKMR6194/Umi.git#*
bower resolve       git@github.com:NKMR6194/Umi.git#*
bower checkout      Umi#v3.3.6-1
bower resolved      git@github.com:NKMR6194/Umi.git#3.3.6-1
bower install       Umi#3.3.6-1

Nicoの場合はv3.3.5の初版はv3.3.5、以降semverフォーマットへの準拠などを経て、v3.3.6の初版を v3.3.6-1.1.0 でリリースしています。この場合どうなるかというと、

% bower install git@github.com:kubosho/Nico.git
bower not-cached    git@github.com:kubosho/Nico.git#*
bower resolve       git@github.com:kubosho/Nico.git#*
bower checkout      Nico#v3.3.5
bower invalid-meta  Nico is missing "main" entry in bower.json
bower invalid-meta  Nico is missing "ignore" entry in bower.json
bower resolved      git@github.com:kubosho/Nico.git#3.3.5
bower install       Nico#3.3.5

Nico#3.3.5 bower_components/Nico

v3.3.6-1.1.0 は無視され、 v3.3.5 が最新版としてインストールされるようです。

検証として以下のリポジトリを作ってみました。

https://github.com/windyakin/bower_test

tagの切り方についてはReleasesのページを見てもらえればわかりますが、途中までハイフン区切り無しでtagを切っていて、途中からハイフン区切りをつけた場合(Umi形式にした場合)、やはりハイフン区切りが無かったv1.0.1が最新版としてインストールされるようです。

% bower install git@github.com:windyakin/bower_test.git
bower not-cached    git@github.com:windyakin/bower_test.git#*
bower resolve       git@github.com:windyakin/bower_test.git#*
bower checkout      bower_test#v1.0.1
bower invalid-meta  bower_test is missing "main" entry in bower.json
bower invalid-meta  bower_test is missing "ignore" entry in bower.json
bower resolved      git@github.com:windyakin/bower_test.git#1.0.1
bower install       bower_test#1.0.1

bower_test#1.0.1 bower_components/bower_test

というわけで現状、HonokaとNicoがUmiのバージョニングに対応した場合Bowerで最新版をインストールするにはやはり今までどおり、バージョンを直接指定するしかなさそうという検証でした。

どうにかできれば一番ですが、どうしたらいいんでしょうね。

@ysakasin
Copy link
Contributor

Bowerでうまく使えるようにしたいということならPATH案が良い気がしますがどうなんですか?

私的にはBowerを全く使っていないので、普段使ってる方の都合を優先したいと思ってます

@kubosho
Copy link
Contributor

kubosho commented Mar 31, 2016

Bowerで上手く使えるようにするという点では、PATCH案がいい気がします。
ただ、これも元のBootstrapのバージョンがどれになるのか分かりにくいという欠点はあり難しいところですね…

@windyakin
Copy link
Owner Author

ひとまずPATCH案で 4.0.0 リリースから統一する方向で調整したいと思ってます

Repository owner locked and limited conversation to collaborators Jan 25, 2017
@windyakin
Copy link
Owner Author

4.0.0 になったし思い出していこうな

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants