バージョン番号の一番末尾の番号にビルド番号を入れる

[m-tmatma]

バージョン番号の一番末尾の番号にビルド番号を入れませんか?

#130 の対応で自動的に EXEのバージョンをインストーラのバージョンを
設定することが可能ですが、appveyor 経由でビルドしたバイナリを使う
人も出て来ると思いますが、

ビルド番号を区別できたほうがいいと思います。

[kobake]

ビルド番号って何でしたっけ？Gitハッシュですかね？

[KENCHjp]

Delphiだと末尾はコンパイルのたびに自動インクリできますが、自動でインクリされる値かなにかハッシュ値みたいなのがつくといいっすかね。
Windowsみたいな#????じゃだめなきがするし。
日時かな。。。

[m-tmatma]

https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.200

の 200 の部分です。

APPVEYOR_BUILD_NUMBER で取れます。

あるいは　バージョン番号に直接 APPVEYOR_BUILD_VERSION を設定してしまってもいいのかも

sakura/appveyor.yml

Line 1 in 53b1d94

version: 1.0.{build}

参考
https://www.appveyor.com/docs/environment-variables/

[m-tmatma]

APPVEYOR_BUILD_VERSION　なりAPPVEYOR_BUILD_NUMBER　の環境変数の値をもとに
バージョン番号を更新するスクリプトを作ってビルドすればいいと思う。

[kobake]

提案内容把握です。

AppVeyorビルド番号をどこかに含めることには賛成ですが、それをバージョン番号の一部に取り込んでしまうというのはあまりしっくり来ません。

例えば https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.200 は
GitHash 44999a5 のビルド成果物を含みますが、
GitHash 44999a5 のビルドは何度もできるため、GitHash が同じだけどバージョン番号の異なる成果物が生じ得る、というのは違和感があります。

GitHash が同じもののビルド成果物のバージョン番号は常に同じであって欲しいです。

以下画像は成果物内 sakura.exe のバージョン情報ですが、
この中には Product version = 2.3.2.0 (GitHash 44989a5) という情報が含まれています。
この例のような形でバージョン番号の付加情報としてビルド番号を含める程度であれば賛成です。
2.3.2.0 (GitHash 44989a5) (Build 1.0.200) のような感じに。ちょっと長い気もしますが。

[kobake]

ちょっと今日は忙しくなりそうなのでまた夜にでも反応します。

[m-tmatma]

GitHash が同じもののビルド成果物のバージョン番号は常に同じであって欲しいです。

GitHash が同じでも例えば appveyor 側が用意する build 用のイメージを変えたら
ビルド成果物は異なるものになる可能性はあります。

この例のような形でバージョン番号の付加情報としてビルド番号を含める程度であれば賛成です。
2.3.2.0 (GitHash 44989a5) (Build 1.0.200) のような感じに。ちょっと長い気もしますが。

例えば windows ではバージョン番号の一部にビルド番号が入っています。
ただビルド番号がわかればビルド番号を追加で入れるのでもいいと思います。

(Build 1.0.200)

ビルド番号は 200 だけです。
1.0 の部分はバージョンです。

[kobake]

例えば windows ではバージョン番号の一部にビルド番号が入っています。

あー、なるほど。そういえば Chrome のバージョン番号とかもそんな感じでしたっけ。今スマホなので確認できないんですけど。

末尾をビルド番号とするのが現代の一般的な慣習であるならば、むしろ大賛成です。ちょっとこのあたりちゃんと意識したことなくてよく分かってませんでした。

[KENCHjp]

APPVEYOR_BUILD_VERSION　なり>APPVEYOR_BUILD_NUMBER　の環境変数の値をもとに
バージョン番号を更新するスクリプトを作ってビルドすればいいと思う。

コレがよさげすかね。みんなの発言をそうごうすると。

スクリプトが必要なのか、コンパイル時のmakeみたいなやつで環境変数からバージョン番号埋め込めないのかしら、、、点在してるんでしたっけ？リソース、なるべく作り物は減らしたいですね。

[kobake]

バージョン番号はいたるところに散在してるので、バージョン番号生成&ぜんぶ自動書き換えするスクリプトは必要になりそうだと思ってます

[KENCHjp]

バージョン番号はいたるところに散在してるので

ソース側で一か所に書いてdefine参照とかできないものっすかねぇ、少なくてもインストーラーのissは #130 で除去されます。

[kobake]

軽く見た感じだとこんなところですね。他にもあるかも。いろんな形式のファイルがある以上はスクリプト必要になるの仕方ないと思ってます。

help\sakura\_RESOURCE\HLP000001.html(18,23)  [SJIS]: <center>サクラエディタ   Ver 2.3.2.0</center>
help\sakura\_RESOURCE\HLP_UR017.html(16,19)  [SJIS]: <h3>May. 2, 2017 (2.3.2.0)</h3>
sakura_core\sakura_rc.rc(37,21)  [SJIS]: #define PR_VER_STR	"2.3.2.0"
sakura_core\sakura_rc.rc(36,17)  [SJIS]: #define PR_VER		2,3,2,0
sakura_lang_en_US\sakura_lang_rc.rc(37,17)  [SJIS]: #define PR_VER		2,3,2,0
help\sakura\_RESOURCE\HLP_UR016.html(76,19)  [SJIS]: <h3>May. 5, 2014 (2.1.1.2)</h3>
installer\sakura.iss(23,20)  [SJIS]: VersionInfoVersion=2.1.1.2
installer\sakura.iss(22,34)  [SJIS]: OutputBaseFilename=sakura_install2-1-1-2

[kobake]

バージョン番号の末尾をビルド番号にするのだとすると、ヘルプ内に記載されているバージョン番号については末尾数字削った記載にするのが良さそうですね。例：Ver 2.3.2 みたいな感じ。

[KENCHjp]

helpは、一か所に持ってて参照する形にしたいっすねぇ。
sakura_core\sakura_rc.rcも、うまく一か所直すと、RP_VAR_STRとRP_VARの両方に反映できるようにしたいっすねぇ。
installer\sakura.issは、なくなります。

[m-tmatma]

sakura_core\sakura_rc.rcも、うまく一か所直すと、RP_VAR_STRとRP_VARの両方に反映できるようにしたいっすねぇ。

こんな感じ?

#define VER_A   2
#define VER_B   3
#define VER_C   2
#define VER_D   0

#define TO_STR(arg)                         #arg
#define MAKE_VERSION_STR(a,b,c,d, sep)      TO_STR(a) sep TO_STR(b) sep TO_STR(c) sep TO_STR(d)
#define MAKE_VERSION_STR_PERIOD(a,b,c,d)    MAKE_VERSION_STR(a,b,c,d, ".")
#define MAKE_VERSION_COMMA(a,b,c,d)         a,b,c,d

#define PR_VER_STR  MAKE_VERSION_STR_PERIOD(VER_A, VER_B, VER_C, VER_D)
#define PR_VER      MAKE_VERSION_COMMA(VER_A, VER_B, VER_C, VER_D)

[m-tmatma]

↑ 間違いがあったので修正

[kobake]

異論もなさそうですし、とりあえずバージョン番号の末尾数字はビルド番号ってことで良さそうですね。

バージョン番号の全体のポリシーもある程度方向性を決めたいと思ってまして、それについては別 Issue 立てます。

[KENCHjp]

"Looks Good To Me”

[m-tmatma]

異論もなさそうですし、とりあえずバージョン番号の末尾数字はビルド番号ってことで良さそうですね。

#324 で PR 投げました。

[m-tmatma]

#324 マージしたので閉じます

[berryzplus]

このissueで確定した旧仕様
　Appveyorのビルド番号を入れる。
　↓
利用できるCIが増えた（Azure PilepinesとGitHub Actions）
　導入時の実装は各CIのビルド番号を出力していた。
　問題点：
　　CIによりビルド番号がズレる。
　　当初「正式版」とするつもりだったAppveyorが、他CIに比べて遅いことが分かった。
　　有償版なら対応できる余地があるが、誰もカネ出す気はなさそうなのでAppveyorの優先度を下げよう、になった。
　↓
CIのビルド番号の代わりに、Gitの累積コミット数を入れるようにした。

• 累積コミット数の取得にgit rev-listを使う #1743

---

何か提案あれば、https://github.com/sakura-editor/sakura/wiki の参加方法のいずれかで連絡するか、2chに書き込んでください。ぼく個人に関して言うとGitHubはほぼ毎日見ます。OSDNフォーラムは半年に１回くらい見ます。Discordは使っていないのでまず入りません。2chは月に一度くらいの頻度で見ています。