バージョン番号ポリシーの策定

[kobake]

「バージョン番号の一番末尾の番号にビルド番号を入れる #153」の Issue により、バージョン番号末尾数字をビルド番号にすることが提案されています。議論の流れからするとこの提案は採用されそうです。

で、バージョン番号全体についてのポリシーもこれを機に定めておきたいです。今までの「なんとなく」ではなく、ちゃんとポリシーを決めて共有して今後にも渡って継続運用できると良いなと思っています。

バージョン番号の慣習

一般的にですが、バージョン番号は以下のような形式をとることが多いみたいです。

MAJOR.MINOR.REVISION.BUILDNUMBER

• 参考: https://softwareengineering.stackexchange.com/questions/24987/what-exactly-is-the-build-number-in-major-minor-buildnumber-revision

現サクラエディタにおけるバージョン番号ポリシーの提案

MAJOR

2 のままで良いと思う。「2」が Unicode 版であることを示すことにする。

今後ものすごい大きな変化があればここの数字を上げる可能性もあり得ますが、今のところ自分ではまだ想像はできません。

MINOR

リリース毎にインクリメントしていく。
ただし、旧来よく見かけられた「奇数は開発中の非安定板」「偶数は安定板」というポリシーを採用したい。

• 参考: https://mag.osdn.jp/05/06/15/037257

このポリシーを採用するとすると、
・次のリリースバージョンは「2.4.x.x」
・その後のリリースまでの繋ぎ（リリースはしない途中開発の状態）のバージョンは「2.5.x.x」
・さらに次のリリースバージョンは「2.6.x.x」
となります。

さらに未来の話をするとどんどんインクリメントは行われるので、「2.10.x.x」とか「2.46.x.x」とか「2.100.x.x」みたいなバージョン番号にもなり得ます。個人的にはこれでも良いと思っていますが、これに対して違和感を持つ人がいるとして、その違和感を許容できるかどうかがキモかと思っています。

REVISION

ここはいわゆるコミット番号（コミット毎にインクリメントされる数値）としたい。

ただ、Subversion の場合にはリビジョンがまさにコミット番号でしたが、今の Git は連番の数値というものは存在しません。が、実際にはビルド時点での「（対象ブランチから見た）全コミット数」をカウントすれば、それがコミット番号の代替となります。この数値を用いたいです。

以下コマンドでコミット数はカウント可。

git log --oneline | wc -l | sed -e "s/[ \t]*//g"

• 参考: https://toris.io/2014/07/git-revision-number-like-svn/

git情報が存在しない環境でのビルドの場合にはここの数値は「0」とする。

BUILDNUMBER

AppVeyor のビルド番号。Build 1.0.200 とあれば、この中の 200 の部分。#153 で議論されている内容。

非AppVeyorビルドの場合にはここの数値は「0」とする。

ご意見ください

どうでしょうか。上に挙げた内容はあくまでもひとつの提案です。
何かご意見あればください。

[KENCHjp]

REVISIONがコミット単位というのは、masterに対してってことですか？
マイナーが上がったら、０リセットする？。。。するのは大変そうっすよね。。。
BUILDNUMBERこっちは、ずっとシーケンシャルに上がっていくってことですよね？

2.48.5128.19827

とかになる可能性あり？

[m-tmatma]

BUILDNUMBERこっちは、ずっとシーケンシャルに上がっていくってことですよね？
2.48.5128.19827
とかになる可能性あり？

各桁16bit までですね。

https://msdn.microsoft.com/en-us/library/aa381058.aspx

FILEVERSION

Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, "FILEVERSION 3,10,0,61" is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).

[m-tmatma]

APPVEYOR_BUILD_NUMBER がいくつまでいけるかは質問しました。
appveyor/ci#2463

[kobake]

REVISIONがコミット単位というのは、masterに対してってことですか？

master でビルドするのであれば master から見たコミット件数になります。

                C   - C
             /               
C - C - C   -  C ← この時点ではコミット件数4件

                C   - C
             /             ＼
C - C - C   -  C   -   C - M - C ← この時点ではコミット件数9件

↑ちょっとすみません、線がずれてますが「M」はマージコミットだと思ってください。

マイナーが上がったら、０リセットする？。。。するのは大変そうっすよね。。。

0 リセットはしない想定で考えています。

BUILDNUMBERこっちは、ずっとシーケンシャルに上がっていくってことですよね？

2.48.5128.19827

とかになる可能性あり？

です。そういう想定です。

16bitだとunsignedだと6万件、signedだと3万件程度までしか対応できませんが。
それはそれで時期が来たらまた考え直すくらいで割り切りたいです。

[berryzplus]

問題ないと思います。

この方式でいくと、今後バージョンについて話すときは
2.4とか2.5とかMajor + Minorだけで話すイメージになると思っています。

3つ目の数字は GitHub を表示したときに出る nCommits の数字、
https://github.com/sakura-editor/sakura

4つ目の数字は appveyor のビルド番号( #165 )、
https://ci.appveyor.com/project/sakuraeditor/sakura

となるのでフル桁のバージョン番号は障害対応のときにだけ出てくるようになる認識。

別案としてはリリース時点の年月(yymm)を2つ目か3つ目に入れて識別する方法を考えました。

リリース年月をバージョンにする方式は Ubuntu と Windows 10 で採用されてる方式です。

どう決めるか、だけの話なので反対意見がなければ @kobake さんの案ですすめてよいと思っています。

[kobake]

この方式でいくと、今後バージョンについて話すときは
2.4とか2.5とかMajor + Minorだけで話すイメージになると思っています。

そうですね。この議論においても一旦 REVISION, BUILDNUMBER についてはブレがなさそうなので一旦記載を略しちゃいます。

リリース年月をバージョンにする方式は Ubuntu と Windows 10 で採用されてる方式です。

知らなかった…。
Ubuntu 17.10 ってあったら 2017年10月版ってことだったんですね…。

https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_18.10_(Cosmic_Cuttlefish)

この場合は MAJOR を年、MINOR を月としていますね。

SakuraEditor 18.06.xxxx.xxxx … これはこれで悪くない気もします…が、めちゃくちゃ番号飛びますねｗ
SakuraEditor 2.1806.xxxx.xxxx … これはちょっと数字の意味の汲み取りがわかりにくそう。慣れの問題でもありますが。
SakuraEditor 2.201806.xxxx.xxxx … こうできれば年月であることがかなり明確になりますけど、16bit 超えちゃいますね。

MINOR に連番（安定板は偶数）を用いるか年月を用いるかは、なんというか好みの問題ですかね。
これについて他の人のご意見も聞きたいです。

[berryzplus]

リリース年月を含めるとしたらwindows10スタイルになると思っています。

https://ja.wikipedia.org/wiki/Microsoft_Windows_10#バージョン履歴

SakuraEditor 2.1806.xxxx.xxxx … これはちょっと数字の意味の汲み取りがわかりにくそう。慣れの問題でもありますが。

指摘はまったくその通りで、ぼく自身も昨年末くらいまで気付いていませんでした。
fall creators updateのときにバージョン一覧みて、「あ」と思ったクチ・・・。

この方式にするならメジャーを 3 にしてしまったほうが分かりやすいのかも知れません。
いまのノリでいくと 3 に移行するのは時期尚早かな、という所感。

あと、ubuntuもそうなんですが、この形式のバージョンを振るものは、
リリースバージョンに「愛称」をつける慣習があるみたいです。
このへんは Eclipse シリーズとも通じるところがあると思っています。

[KENCHjp]

ちなみに、sakura本体で、バージョン番号に依存した処理って無いって思っていいですか？
私のソフトは、過去のdata(Iniファイル)を読むときにiniファイル内のバージョン番号によって、中のデータを加工して最新の形式にコンバートする処理があります。
（昔Iniしかなかったので、固定長レコード+末尾可変データみたいな形式だったので、xmlとかyamlとかだったらそんなことしなくてよかったのかもしれませんけど)

[kobake]

sakura/sakura_core/config/system_constants.h

Line 546 in f216507

#define N_SHAREDATA_VERSION 172

一応ここでプロセス間共有メモリ形式のバージョンがあったりしますけど、ソフトウェアのバージョンとは独立した番号になってるので影響無しという認識です。

過去のソフトウェアバージョン番号変更のときにも特段データ形式を意識するようなコミットを見た記憶は無いです。

ini の形式を将来がっつり変更することがあったとしても、そこはソフトウェアバージョンで判定というよりは ini 自体にバージョンを持たせるのが安全で柔軟ではないかな、と思っています。

ところで本 Issue の話とは関係ないですけど、32bit 版と 64bit 版でたぶん共有メモリの構造（数値系のサイズ）が変わると思うので、このあたりは混ざらないように考えておく必要はありそうです。

[m-tmatma]

@kobake さん

リンクは、pamanent link で書くのが、いいです。
後で行がずれるかもしれないです。

[KENCHjp]

@kobake さん、了解です。

[kobake]

パーマリンクおけです

[kobake]

パーマリンクに変更しておきました

[berryzplus]

私のソフトは、過去のdata(Iniファイル)を読むときにiniファイル内のバージョン番号によって、中のデータを加工して最新の形式にコンバートする処理があります。

サクラエディタにも、古いsakura.iniを読み込むときのコンバート処理があったような気がするんですが・・・。
CShareData_IO::LoadShareData() が呼び出してる処理のどこかです。
たしか項目名を読み替える処理だった気がします。
見つからないので「ない」ってことでもいいかな、と。

ところで本 Issue の話とは関係ないですけど、32bit 版と 64bit 版でたぶん共有メモリの構造（数値系のサイズ）が変わると思うので、このあたりは混ざらないように考えておく必要はありそうです。

これについては対応不要な認識です。
現状のままだと 32bit版 と 64bit版 は干渉しないので、同時に起動させることができます。

sakura/sakura_core/config/system_constants.h

Lines 60 to 65 in f216507

	//! ターゲットマシン判別 2010.08.21 Moca 追加
	#ifdef _WIN64
	#define CON_SKR_MACHINE_SUFFIX_ "M64"
	#else
	#define CON_SKR_MACHINE_SUFFIX_ ""
	#endif

共有メモリの名前をシンボル定義する際に、x86/x64を識別する名前を含めています。
kobake さんが貼ったリンクの2行下です。

sakura/sakura_core/config/system_constants.h

Line 548 in f216507

#define GSTR_SHAREDATA (_T("SakuraShareData") _T(CON_SKR_MACHINE_SUFFIX_) _T(_CODE_SUFFIX_) _T(_DEBUG_SUFFIX_) _T(STR_SHAREDATA_VERSION))

ここに載ってるパラメタのいずれかが異なれば同時起動可能です。
Debug/Releaseも同時起動可能 😄

[KageShiron]

安定版偶数、開発版偶数は、並行でメンテナンスを続けるような場合のバージョニングではないでしょうか？開発版を利用するのは特殊な人ですし、ベースのバージョン番号とビルド番号で見分けるで十分かなと思います。

2.4とか2.5とかMajor + Minorだけで話すイメージになると思っています。

これに関しては混乱を呼ぶだけな気がします。例えば、インストーラやヘルプファイルの更新でMinorが上がらないと2.4が複数種類配られたり。

そういえば、開発フローはGitLab Flowとかを採用するのでしょうか？

[KageShiron]

平成30年だから、2.3006・・・！

[kobake]

自分の中では、仮に ver 2.4 をリリースしたとしたら、リリース直後に master でのバージョン番号を 2.5 に上げてしまって、リリース版と開発途中版の見分けが付くようにできると良いなーとか思ったりしてました。これが一般的かどうかは分かってないのですが。

開発フローはGitLab Flowとかを採用するのでしょうか？

あんまりそこはちゃんと考えていませんが、個人的には GitHub Flow くらいで良いかなと思っています。

平成30年だから、2.3006・・・！

来年に 01 に戻りますねｗ

[KageShiron]

GitHub Flowは、サーバーで動かすよう常時本番投入可能なソフトを高速で開発していく手法で、リリースを区切る通常のソフトにはいまいちかみ合わせが悪いらしいです。(イマイチ理解しきれてないですが・・・)

仮に ver 2.4 をリリースしたとしたら、リリース直後に master でのバージョン番号を 2.5 に上げてしまって

微修正(例えば、リリース後に特定の環境でインストーラがうまく動かないとか、ヘルプファイルの修正とか)でも2.6をリリースするんでしょうか？

2.4から分岐するにしても、revisionにコミット数が入っていると事前に手順を考えておかないと面倒が生じそう

[kobake]

微修正リリースが必要な場合は hotfix として 2.4.aaa.bbb から分岐した 2.4.ccc.ddd をブランチ分けて作る感じを考えていましたが、どういう問題が発生するのかいまいち想像できないです。

aaa よりも ccc は必ず大きい数字になるので、ここが問題になることは考えてないです。

いまいちかみ合わせが悪いらしいです。(イマイチ理解しきれてないですが・・・)

自分もいまいち理解しきれてないです…。その場その場の思い付き対応でも帳尻合えば良いかなーと楽観的に考えていました。

[KageShiron]

多分私の違和感はここらへんです。

• 全く内容の違う2.4.1000.xと、2.5.1000.xが同時に存在して良いのか(別に良い気もしてきた)
• 2.4.1000.xの修正版として2.4.1001.xを一般公開する可能性があるなら、「2.4とか2.5とかMajor + Minorだけで話すイメージになると思っています。」に反しそう。少なくとも、2.4(インストーラ修正版)みたいな名前で公表するのは避けたい

https://postd.cc/gitlab-flow/

によると、masterに入れる→安定版ブランチにCherry Pickが良いらしいです

[kobake]

全く内容の違う2.4.1000.xと、2.5.1000.xが同時に存在して良いのか(別に良い気もしてきた)

良いと思ってます。

場合によっては 2.4.1010.x と 2.5.1000.x のように、2.4 側の REVISION が大きくなることもあり得ますが。特に混乱は生まれない…はず、と考えています。

2.4.1000.xの修正版として2.4.1001.xを一般公開する可能性があるなら、「2.4とか2.5とかMajor + Minorだけで話すイメージになると思っています。」に反しそう。少なくとも、2.4(インストーラ修正版)みたいな名前で公表するのは避けたい

そうですね、当初 hotfix のことは考えていませんでしたが、それ込みで考えると利用者の方々にも REVISION まで含めたバージョンを意識してもらう必要がありそうです。

Issue でバグ報告受けるときにはバージョン番号をぜんぶ書いてもらうように Issue Template で促そうかと考えています。
今草稿中の Issue Template を https://github.com/sakura-editor/sandbox/issues/new?template=1_bug.md から見れます。

https://postd.cc/gitlab-flow/

によると、masterに入れる→安定版ブランチにCherry Pickが良いらしいです

ちょっとここはあとで時間あるときに見てみます。

[m-tmatma]

git log --oneline | wc -l | sed -e "s/[ \t]*//g"

REVISION に関してですが、
windows では wc も sed もないので、HeaderMake や MakefileMake などユーティリティを
作ってビルドに使うのと同様に行番号を数える小さなユーティリティを作ればいいと思います。

cygwin とか入れればいいのかもしれませんが、そのために cygwin への依存は入れたくない。

[kobake]

もし PowerShell が使えるならそれでやりたいです。自分のほうでやっていた検証は途中で止まってしまってますが。

[m-tmatma]

https://qiita.com/cd01/items/da9a36582372e7d0a7f6
こんなサイトありました

[berryzplus]

Appveyorにはmsys入ってるので簡単なユーティリティは普通に使える認識です。

誰か試した人いないかしら。

[m-tmatma]

いけますね。

• https://ci.appveyor.com/project/m-tmatma/test-git-log-oneline/build/1.0.2
• https://github.com/m-tmatma/test-git-log-oneline/blob/551838c3b3a1d27afc32cdd55ea0343af0767136/show-rev.bat

[KageShiron]

全く内容の違う2.4.1000.xと、2.5.1000.xが同時に存在して良いのか(別に良い気もしてきた)

良いと思ってます。
場合によっては 2.4.1010.x と 2.5.1000.x のように、2.4 側の REVISION が大きくなることもあり得ますが。特に混乱は生まれない…はず、と考えています。

了解です。自分の頭でリビジョン=ソースコードバージョンぐらいで考えていたので混乱してました^^;

Issue Template

開発版ではmaster以外のブランチの自己ビルドをバージョン番号からは特定できないので、ハッシュ値も書くように明記したほうが良いかもしれません。(2.5.1000.0はブランチごとに複数存在しえます)

[kobake]

開発版ではmaster以外のブランチの自己ビルドをバージョン番号からは特定できないので、ハッシュ値も書くように明記したほうが良いかもしれません。(2.5.1000.0はブランチごとに複数存在しえます)

ハッシュ値はあったほうが好ましいですね。

ですが人によっては ZIP からダウンロードしたものをビルドする人もいたりして、そうするとダウンロード時点でのハッシュを覚えていないと、ZIP 解凍物からは Git 関連情報が何もない（2.5.0.0 みたいになる）ので、うーんってところですけど、まぁそれは問題になったときに考えようと思います。

開発途上版をダウンロードする人は AppVeyor 成果物のほうを使ってもらうように README で促すとかは考えています。

[KENCHjp]

あえて 2.4.6 を使わずに 2.4.2 が hotfix であることを意識して使おうとしてくれる人ってほとんどいない気がします。アナウンスの仕方で工夫・・・ですかね？

これがどれぐらいの致命的不具合かどうかですが、使ってて致命傷であれば、2.4.2を使ってもらえるかとおもいます。
また、致命傷の場合、いったん2.4.6はリリース（ダウンロードページ等）からは削除して、
2.4.7を出す間の最終リリースは2.4.2を公開していればいいように思いますがいかがでしょう。

これ、例えば2.4.6を使ってるユーザーで特に困ってない（その致命傷の機能に該当しない）人が、
そろそろバージョンアップしようかーみたいな感じで、公サイトに訪れて、まだ2.4.7が公開されてない状態で、2.4.2使ってねってかいてあれば2.4.2にするか2.4.6を使い続けてもいいやって判断して、2.4.7が公開されてれば普段通り2.4.7にアップロードするような。

[kobake]

ふむふむ。運用でカバーですかね。
他の方の意見も聞いてみたいです。

[kobake]

間違えてクローズしちゃってました。reopen.

[kobake]

少し考えたのですが、そもそも旧版からのhotfixを考えずに常に最新リリース版からのhotfix切るようにすればリビジョン巻き戻り問題起こらなくなりますね。

[kobake]

↑(少なくともリリース版に限っては)

[berryzplus]

リリースには必ず手作業が入るので、バージョンの末尾に元にしたバージョンを添えてhotfixである旨表示してはどうでしょうか？

混乱や間違いは防げると思います。

[k-takata]

独自ルールで悩むくらいなら、semantic versioning に倣ってもよいのではないでしょうか。現状最も広く使われているルールだと思います。(どちらかというとアプリではなくライブラリを意識したルールですが。)

• 2.4.xx は、基本的には 2.4.0 に対するバグフィックスのみ。(小さな機能追加ぐらいは入れてもいいかも)
• 既に2.4.6をリリースしたなら、2.4系に対するhotifixは2.4.7として出す。(2.4.1から分岐させたりはしない。)
• 機能追加をしたなら次のリリースは 2.5.0。

semantic versioningを使うなら、自動更新するのはビルド番号のみ (a.b.c.d の d のみ) になるでしょう。
（ちなみに今、奇数偶数方式を使っているメジャーなプロジェクトはPerlぐらい？）

[kobake]

（ちなみに今、奇数偶数方式を使っているメジャーなプロジェクトはPerlぐらい？）

奇数偶数方式ってそこまで廃れちゃってましたか……（廃れ具合はちゃんと調べてなかったです）

[KENCHjp]

@k-takata さん、おおそんなのもあるんですね。
勉強なります。

[KENCHjp]

semantic versioning を採用しても「１．」のアンケートと矛盾はないっすね。

[berryzplus]

機能が追加されたらマイナーアップということなら次バージョンは2.4確定ですね。

2.3のあとに追加された機能がいくつかあるので。

[kobake]

@k-takata

独自ルールで悩むくらいなら、semantic versioning に倣ってもよいのではないでしょうか。現状最も広く使われているルールだと思います。(どちらかというとアプリではなくライブラリを意識したルールですが。)

良いと思います。
今風のルールがあるならそっちに乗っかるのが良さそうですね。

　

@berryzplus

機能が追加されたらマイナーアップということなら次バージョンは2.4確定ですね。

2.3のあとに追加された機能がいくつかあるので。

2.4 で良いと思います。

ただ、 @k-takata さんがおっしゃられている、

2.4.xx は、基本的には 2.4.0 に対するバグフィックスのみ。(小さな機能追加ぐらいは入れてもいいかも)

という文面からは「小さな機能追加程度であれば MINOR は上げるまでもない」という意味であると自分は汲み取りました。

現時点からの次リリースは割といろいろ変更入ることが想定されるので MINOR は上げる確定で良いと思っていますが、今後も機能が何かしら追加されたからといって MINOR を必ず上げる必要があるかというと、そのあたりは雰囲気で判断になると思います。

[kobake]

semantic versioning、良いと思いますが、皆さんどうでしょう。

semantic versioningを使うなら、自動更新するのはビルド番号のみ (a.b.c.d の d のみ) になるでしょう。

d 部分はビルド番号で良いでしょうか。
コミット番号という選択肢もあるように思いましたが、いまいちここの番号をどうすべきか判断に迷っています。

[kobake]

あと、ひとつ気になっているのが、仮に semantic versioning を採用して 2.4.0.d をリリースしたとして、次のリリースまでの間、2.4.c.d の c 部分の値は維持したままでコミットを積んでいくことになるでしょうか。

個人的には 2.4.0.d をリリースした直後に GitHub ソースコード内のバージョンは 2.4.1.d に上げてしまったほうが、リリース版とそれ以外が区別できてありがたいと思っています。（結局ここで奇数偶数の話のぶり返しになってしまうのですが）

[KENCHjp]

結局ここで奇数偶数の話のぶり返しになってしまうのですが）

「リリース後に上げましょう」はキメなのでいいと思います。
「リリース以外では上げません」は決まってないと思いますので、必ずしも奇数偶数の議論のぶり返しではないと思われます。

[k-takata]

実のところ semantic versioningのバージョン表記は、major.minor.patch(-prerelease)(+buildmetadata) ですので、a.b.c.d という表記は許可されていません。なので厳密に従うならば、例えば以下のようになるでしょう。

• リリース版:
  • 公式なバージョン名は a.b.c として、d (ビルド番号or コミット番号)はあくまで補足情報としておく
  • あるいは a.b.c+d 表記にする
• プレリリース版:
  • a.b.c-d 等の表記にする (2.4.1-123, 2.4.1-dev123, etc.)

(semantic versioningは参考にしただけということにして a.b.c.d 表記を通すのもありかもしれませんが。)

個人的には 2.4.0.d をリリースした直後に GitHub ソースコード内のバージョンは 2.4.1.d に上げてしまったほうが、リリース版とそれ以外が区別できてありがたいと思っています。

semantic versioningに従うなら、バージョンを上げてしまって、上に書いたように 2.4.1-d などの表記になればよさそうです。

[kobake]

なるほど〜、勉強になります。ご解説ありがとうございます。これをもとにもう少し案練ってみます。

[berryzplus]

これ、だいぶ前に決まった認識なので閉じてしまいます。