-
Notifications
You must be signed in to change notification settings - Fork 162
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
バージョン番号ポリシーの策定 #168
Comments
REVISIONがコミット単位というのは、masterに対してってことですか? 2.48.5128.19827 とかになる可能性あり? |
各桁16bit までですね。 https://msdn.microsoft.com/en-us/library/aa381058.aspx FILEVERSION
|
APPVEYOR_BUILD_NUMBER がいくつまでいけるかは質問しました。 |
master でビルドするのであれば master から見たコミット件数になります。
↑ちょっとすみません、線がずれてますが「M」はマージコミットだと思ってください。
0 リセットはしない想定で考えています。
です。そういう想定です。 16bitだとunsignedだと6万件、signedだと3万件程度までしか対応できませんが。 |
問題ないと思います。 この方式でいくと、今後バージョンについて話すときは 3つ目の数字は GitHub を表示したときに出る nCommits の数字、 4つ目の数字は appveyor のビルド番号( #165 )、 となるのでフル桁のバージョン番号は障害対応のときにだけ出てくるようになる認識。 別案としてはリリース時点の年月(yymm)を2つ目か3つ目に入れて識別する方法を考えました。 リリース年月をバージョンにする方式は Ubuntu と Windows 10 で採用されてる方式です。 どう決めるか、だけの話なので反対意見がなければ @kobake さんの案ですすめてよいと思っています。 |
そうですね。この議論においても一旦 REVISION, BUILDNUMBER についてはブレがなさそうなので一旦記載を略しちゃいます。
知らなかった…。 https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_18.10_(Cosmic_Cuttlefish) この場合は MAJOR を年、MINOR を月としていますね。
MINOR に連番(安定板は偶数)を用いるか年月を用いるかは、なんというか好みの問題ですかね。 |
リリース年月を含めるとしたらwindows10スタイルになると思っています。 https://ja.wikipedia.org/wiki/Microsoft_Windows_10#バージョン履歴
指摘はまったくその通りで、ぼく自身も昨年末くらいまで気付いていませんでした。 この方式にするならメジャーを 3 にしてしまったほうが分かりやすいのかも知れません。 あと、ubuntuもそうなんですが、この形式のバージョンを振るものは、 |
ちなみに、sakura本体で、バージョン番号に依存した処理って無いって思っていいですか? |
sakura/sakura_core/config/system_constants.h Line 546 in f216507
一応ここでプロセス間共有メモリ形式のバージョンがあったりしますけど、ソフトウェアのバージョンとは独立した番号になってるので影響無しという認識です。 過去のソフトウェアバージョン番号変更のときにも特段データ形式を意識するようなコミットを見た記憶は無いです。 ini の形式を将来がっつり変更することがあったとしても、そこはソフトウェアバージョンで判定というよりは ini 自体にバージョンを持たせるのが安全で柔軟ではないかな、と思っています。 ところで本 Issue の話とは関係ないですけど、32bit 版と 64bit 版でたぶん共有メモリの構造(数値系のサイズ)が変わると思うので、このあたりは混ざらないように考えておく必要はありそうです。 |
@kobake さん リンクは、pamanent link で書くのが、いいです。 |
@kobake さん、了解です。 |
パーマリンクおけです |
パーマリンクに変更しておきました |
サクラエディタにも、古いsakura.iniを読み込むときのコンバート処理があったような気がするんですが・・・。
これについては対応不要な認識です。 sakura/sakura_core/config/system_constants.h Lines 60 to 65 in f216507
共有メモリの名前をシンボル定義する際に、x86/x64を識別する名前を含めています。 sakura/sakura_core/config/system_constants.h Line 548 in f216507
ここに載ってるパラメタのいずれかが異なれば同時起動可能です。 |
安定版偶数、開発版偶数は、並行でメンテナンスを続けるような場合のバージョニングではないでしょうか?開発版を利用するのは特殊な人ですし、ベースのバージョン番号とビルド番号で見分けるで十分かなと思います。
これに関しては混乱を呼ぶだけな気がします。例えば、インストーラやヘルプファイルの更新でMinorが上がらないと2.4が複数種類配られたり。 そういえば、開発フローはGitLab Flowとかを採用するのでしょうか? |
平成30年だから、2.3006・・・! |
自分の中では、仮に ver 2.4 をリリースしたとしたら、リリース直後に master でのバージョン番号を 2.5 に上げてしまって、リリース版と開発途中版の見分けが付くようにできると良いなーとか思ったりしてました。これが一般的かどうかは分かってないのですが。
あんまりそこはちゃんと考えていませんが、個人的には GitHub Flow くらいで良いかなと思っています。
来年に 01 に戻りますねw |
GitHub Flowは、サーバーで動かすよう常時本番投入可能なソフトを高速で開発していく手法で、リリースを区切る通常のソフトにはいまいちかみ合わせが悪いらしいです。(イマイチ理解しきれてないですが・・・)
微修正(例えば、リリース後に特定の環境でインストーラがうまく動かないとか、ヘルプファイルの修正とか)でも2.6をリリースするんでしょうか? 2.4から分岐するにしても、revisionにコミット数が入っていると事前に手順を考えておかないと面倒が生じそう |
微修正リリースが必要な場合は hotfix として 2.4.aaa.bbb から分岐した 2.4.ccc.ddd をブランチ分けて作る感じを考えていましたが、どういう問題が発生するのかいまいち想像できないです。 aaa よりも ccc は必ず大きい数字になるので、ここが問題になることは考えてないです。
自分もいまいち理解しきれてないです…。その場その場の思い付き対応でも帳尻合えば良いかなーと楽観的に考えていました。 |
多分私の違和感はここらへんです。
によると、masterに入れる→安定版ブランチにCherry Pickが良いらしいです |
良いと思ってます。 場合によっては 2.4.1010.x と 2.5.1000.x のように、2.4 側の REVISION が大きくなることもあり得ますが。特に混乱は生まれない…はず、と考えています。
そうですね、当初 hotfix のことは考えていませんでしたが、それ込みで考えると利用者の方々にも REVISION まで含めたバージョンを意識してもらう必要がありそうです。 Issue でバグ報告受けるときにはバージョン番号をぜんぶ書いてもらうように Issue Template で促そうかと考えています。
ちょっとここはあとで時間あるときに見てみます。 |
REVISION に関してですが、 cygwin とか入れればいいのかもしれませんが、そのために cygwin への依存は入れたくない。 |
もし PowerShell が使えるならそれでやりたいです。自分のほうでやっていた検証は途中で止まってしまってますが。 |
Appveyorにはmsys入ってるので簡単なユーティリティは普通に使える認識です。 誰か試した人いないかしら。 |
了解です。自分の頭でリビジョン=ソースコードバージョンぐらいで考えていたので混乱してました^^;
開発版ではmaster以外のブランチの自己ビルドをバージョン番号からは特定できないので、ハッシュ値も書くように明記したほうが良いかもしれません。(2.5.1000.0はブランチごとに複数存在しえます) |
ハッシュ値はあったほうが好ましいですね。 ですが人によっては ZIP からダウンロードしたものをビルドする人もいたりして、そうするとダウンロード時点でのハッシュを覚えていないと、ZIP 解凍物からは Git 関連情報が何もない(2.5.0.0 みたいになる)ので、うーんってところですけど、まぁそれは問題になったときに考えようと思います。 開発途上版をダウンロードする人は AppVeyor 成果物のほうを使ってもらうように README で促すとかは考えています。 |
これがどれぐらいの致命的不具合かどうかですが、使ってて致命傷であれば、2.4.2を使ってもらえるかとおもいます。 これ、例えば2.4.6を使ってるユーザーで特に困ってない(その致命傷の機能に該当しない)人が、 |
ふむふむ。運用でカバーですかね。 |
間違えてクローズしちゃってました。reopen. |
少し考えたのですが、そもそも旧版からのhotfixを考えずに常に最新リリース版からのhotfix切るようにすればリビジョン巻き戻り問題起こらなくなりますね。 |
↑(少なくともリリース版に限っては) |
リリースには必ず手作業が入るので、バージョンの末尾に元にしたバージョンを添えてhotfixである旨表示してはどうでしょうか? 混乱や間違いは防げると思います。 |
独自ルールで悩むくらいなら、semantic versioning に倣ってもよいのではないでしょうか。現状最も広く使われているルールだと思います。(どちらかというとアプリではなくライブラリを意識したルールですが。)
semantic versioningを使うなら、自動更新するのはビルド番号のみ (a.b.c.d の d のみ) になるでしょう。 |
奇数偶数方式ってそこまで廃れちゃってましたか……(廃れ具合はちゃんと調べてなかったです) |
@k-takata さん、おおそんなのもあるんですね。 |
semantic versioning を採用しても「1.」のアンケートと矛盾はないっすね。 |
機能が追加されたらマイナーアップということなら次バージョンは2.4確定ですね。 2.3のあとに追加された機能がいくつかあるので。 |
良いと思います。
2.4 で良いと思います。 ただ、 @k-takata さんがおっしゃられている、
という文面からは「小さな機能追加程度であれば MINOR は上げるまでもない」という意味であると自分は汲み取りました。 現時点からの次リリースは割といろいろ変更入ることが想定されるので MINOR は上げる確定で良いと思っていますが、今後も機能が何かしら追加されたからといって MINOR を必ず上げる必要があるかというと、そのあたりは雰囲気で判断になると思います。 |
semantic versioning、良いと思いますが、皆さんどうでしょう。
d 部分はビルド番号で良いでしょうか。 |
あと、ひとつ気になっているのが、仮に semantic versioning を採用して 2.4.0.d をリリースしたとして、次のリリースまでの間、2.4.c.d の c 部分の値は維持したままでコミットを積んでいくことになるでしょうか。 個人的には 2.4.0.d をリリースした直後に GitHub ソースコード内のバージョンは 2.4.1.d に上げてしまったほうが、リリース版とそれ以外が区別できてありがたいと思っています。(結局ここで奇数偶数の話のぶり返しになってしまうのですが) |
「リリース後に上げましょう」はキメなのでいいと思います。 |
実のところ semantic versioningのバージョン表記は、
(semantic versioningは参考にしただけということにして
semantic versioningに従うなら、バージョンを上げてしまって、上に書いたように |
なるほど〜、勉強になります。ご解説ありがとうございます。これをもとにもう少し案練ってみます。 |
これ、だいぶ前に決まった認識なので閉じてしまいます。 |
「バージョン番号の一番末尾の番号にビルド番号を入れる #153」の Issue により、バージョン番号末尾数字をビルド番号にすることが提案されています。議論の流れからするとこの提案は採用されそうです。
で、バージョン番号全体についてのポリシーもこれを機に定めておきたいです。今までの「なんとなく」ではなく、ちゃんとポリシーを決めて共有して今後にも渡って継続運用できると良いなと思っています。
バージョン番号の慣習
一般的にですが、バージョン番号は以下のような形式をとることが多いみたいです。
現サクラエディタにおけるバージョン番号ポリシーの提案
MAJOR
2 のままで良いと思う。「2」が Unicode 版であることを示すことにする。
今後ものすごい大きな変化があればここの数字を上げる可能性もあり得ますが、今のところ自分ではまだ想像はできません。
MINOR
リリース毎にインクリメントしていく。
ただし、旧来よく見かけられた「奇数は開発中の非安定板」「偶数は安定板」というポリシーを採用したい。
このポリシーを採用するとすると、
・次のリリースバージョンは「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情報が存在しない環境でのビルドの場合にはここの数値は「0」とする。
BUILDNUMBER
AppVeyor のビルド番号。
Build 1.0.200
とあれば、この中の200
の部分。#153 で議論されている内容。非AppVeyorビルドの場合にはここの数値は「0」とする。
ご意見ください
どうでしょうか。上に挙げた内容はあくまでもひとつの提案です。
何かご意見あればください。
The text was updated successfully, but these errors were encountered: