開発中のバージョン表記について

[arigayas]

#431 (comment) からのissue登録です。

#683 のスクリーンショットを見て思ったのですが
次期バージョンの番号(2.4.0？)が決まっているのなら、
開発バージョンが「sakura(Alpha Version) 2.3.2.0」となっているのは
違和感(＊)があるので更新された方が良いのでは？と思いました。

(＊)違和感というのは、もうすでに2.3.2.0がリリースされているのに
このバージョン番号でアルファ版で開発がされていると勘違いされる可能性がある点です。

現行の表記）　sakura(Alpha Version) 2.3.2.xxxx

個人的にはこちら）　sakura 2.4 Alpha Version 2.4.0.xxxx [xxxxはビルド番号]

開発版で次のリリースバージョンの数字が決まった時点で
バージョンの数字は更新されるのが良いと思います。

[KageShiron]

基本的には賛成です。

2.4.0が完成したらReleaseブランチを切って、masterは2.4.1(α)に。
2.4.0の微小な修正はfotfixブランチで行う。

とすればリリース(修正前)<リリース(修正後)<時期開発版 となることが常に保証される・・・はず

関連 #168

[berryzplus]

一点引っかかってることがあります。

個人的にはこちら）　sakura 2.4 Alpha Version 2.4.0.xxxx [xxxxはビルド番号]

これなんですけど、sakura 2.4 Alpha で v2.4.0.xxxx だとおかしい気がするんです。
sakura 次バージョン Alpha v現バージョン なら分かるんです。

alpha(α版) とか beta(β版) とかっていうのは未リリースバージョンに対して出すものだと思っていて、
2.4 alpha にバージョン 2.4 を振るのに違和感があります。
バージョンを 2.4.0.xxxx とするなら 2.5 Alpha にしたい個人的感想なわけです。

[KageShiron]

(おっと、#168を誤読してました。細微な修正(Hotfix)を当てると2.4.1、2.4.2となっていくので、masterは2.5 αですね。)

@berryzplus
現状→sakura 2.4 Alpha Version 2.3.2.xxxx
2.4.0正式リリース後→sakura 2.5 Alpha Version 2.4.0.xxxxx

としたいということでしょうか？それだと、HotFixの適用状況次第でリリース版2.4.1.xxxと開発版2.4.0.yyyといった状況になってしまう状況がありそうです。

Semantic Versioningだと2.4.0-previewXXXX みたいにして2.4.0の開発版だと表すようです。一般の人にわかりにくければ「2.4系開発版」とかにすれば違和感が減るかもしれません。

// そういえば、サクラエディタのアルファベット表記はSAKURAに統一するのでは

[KENCHjp]

// そういえば、サクラエディタのアルファベット表記はSAKURAに統一するのでは

SAKURA Editorですが、ゆるりといきましょう。

[arigayas]

一点引っかかってることがあります。

個人的にはこちら）　sakura 2.4 Alpha Version 2.4.0.xxxx [xxxxはビルド番号]

これなんですけど、sakura 2.4 Alpha で v2.4.0.xxxx だとおかしい気がするんです。
sakura 次バージョン Alpha v現バージョン なら分かるんです。

alpha(α版) とか beta(β版) とかっていうのは未リリースバージョンに対して出すものだと思っていて、
2.4 alpha にバージョン 2.4 を振るのに違和感があります。
バージョンを 2.4.0.xxxx とするなら 2.5 Alpha にしたい個人的感想なわけです。

現状の表記に引っ張られて書いてしまったので以下に訂正します。

SAKURA Editor 2.4.0.xxxx Alpha Version

[xxxxはビルド番号]で SAKURA Editor 2.4.0 がリリースされたら、
(次のバージョンの数字が仮に2.5.0になったとして)
次のバージョンの開発版は、

SAKURA Editor 2.5.0.xxxx Alpha Version

[xxxxはビルド番号]となる運用かなと思ってます。

自分としては、次のバージョン番号の後ろにalpha(α版) とか beta(β版) とか表記があるのが馴染みがあるんです。
例えば、Mozilla Firefox です。
開発版の特定のビルド番号でBugが発生した場合にどの時点のソースコードか区別が付くから必要かなぁ？と思ってます。

リリース版では、

SAKURA Editor 2.4.0.xx
[xxは0から始まって、HotFixの適用したらxの数字が1ずつ上がる]
で SAKURA Editor 2.4.0 がリリース後にHotFix版がリリースされたら
SAKURA Editor 2.4.0.1
になって次のバージョンは
(次のバージョンの数字が仮に2.5.0になったとして)
SAKURA Editor 2.5.0.xx
[xxは0にリセットされてHotFixが含まれたバージョンになる]
になるのが良いかな？と思ってます。

[berryzplus]

疑問解消です。
これだけならすぐに入れてもいいんじゃないかと思います。どうでしょう？ > @m_tmatma さん

[m-tmatma]

私は TortoiseSVN 方式を押したいと思います。
https://nightlybuilds.tortoisesvn.net/latest/win32/full/

現状 TortoiseSVN のリリース版バージョンでの最新版は 1.11.0 です。

それで subversion 1.11.1 がリリースされたときや TortoiseSVN で
マイナーチェンジがあると 1.11.1 がリリースされます。

subversion 1.12.0 がリリースされるタイミングで次のメジャーリリースである
TortoiseSVN 1.12.0 がリリースされますが、trunk で開発されている nightly ビルドは
TortoiseSVN-1.11.99.28452-dev-win32-ipv6-svn-1.11.dev.msi
のように 1.11 の次の桁が 99になっています。

1.11.x が今後リリースを重ねても 99までは到達しないということから
このように 99を割り当てて、3つ目の数字が 99なら、trunk からの
開発版ということを表しています。

この方式の利点は、単に以下で VER_C の値を 99にするだけで済むことです。
(999とかでも十分大きな値で 9のゾロ目だとなんでもいいと思います。)

sakura/sakura_core/version.h

Lines 7 to 16 in 0c67570

	// バージョン定義 //
	// ver a.b.c.d
	// 例: ver 2.3.2.0
	// a => 2
	// b => 3
	// c => 2
	// d => 0
	#define VER_A 2 // a of ver a.b.c.d
	#define VER_B 3 // b of ver a.b.c.d
	#define VER_C 2 // c of ver a.b.c.d

[berryzplus]

おっ？何気に違う話がはじまった？

現状） SAKURA editor Alpha Version (2.3.2.xxx)
提案）SAKURA editor 2.3.2.xxx Alpha Version

という認識で「これだけなら」と書きました。
m_tmatma さんの話だと新要素が加わりそうな気配。

現状） SAKURA editor Alpha Version (2.3.2.xxx)
提案）SAKURA editor 2.3.2.xxx Alpha Version
追加）SAKURA editor 2.3.2.9xxx Alpha Version

あれ？

[ds14050]

サクラエディタの Alpha はバージョン番号に付随するαリリース、βリリース、リリースキャンディデイトのようなものではなく、x64 ビルドの位置づけを表すものだという認識が共有されていない気がします。

[m-tmatma]

追加）SAKURA editor 2.3.2.9xxx Alpha Version

ちょっと違います。

TortoiseSVN を真似て SAKURA editor 2.3.99.xxx または SAKURA editor 2.3.99.xxx-devです。
(-dev はあってもなくてもいいです)

Alpha Version は @ds14050 さんのコメントの通り、x64 が未完成というのを表したいから
つけているものです。 #162

[KENCHjp]

そっすね、なんか話がごっちゃですね。
Alpha Versionはx64が正式リリースではないってことですよね。
appveyorでコンパイルされているものは、中間生成物で正式リリースではないので、
末尾、2.3.0.xxxxのxxxxがゼロじゃなければ開発中なんですよね。(今のところ)

で、 @arigayas さんがひっかかってる2.3.2.0がリリースされているのに、アルファバージョンが同じバージョン番号で出ているのが引っかかってるってことかと思うのですが、
x64のAlphaとは違いますよね。

ただ今のルールだと、
2.4.0.xxxが出た後、appveyorには、2.4.0.xxx+αが公開されるので正式リリースと区別つきにくいって話がうらにあるのかなって思ったのですが。
そういう意味だと、 @m-tmatma さん提案の、appveyorでコンパイルしている正式リリースではないものには「-dev」がついて、正式リリース版のみ「-dev」が付かないってのが明確にわかりやすいのかも。

または、最後が０のみ正式リリースにしちゃうとか（バグ対緊急リリースも、３桁目を上げて末尾はゼロとか）

[arigayas]

KENCHjp さんのおっしゃるとおりです。

2.3.2.0がリリースされているのに、アルファバージョンが同じバージョン番号で出ているのが引っかかってる

リリースしようとしているバージョン番号に-devが付くようになるのが良いと思います。
64bit版には「Alpha Version」を付与する事になっているということなら、
「Alpha Version」だけだと伝わりにくいと思うのでバージョン番号に64bitを含めるのはどうでしょうか？

バージョン情報とウィンドウタイトルでのバージョン表記が一致してないは、ちょっと混乱しました。
別のissueとして登録？
以下はローカルビルドでの表記です。

現状のバージョン情報でのバージョン表記

32bit

デバッグ版 | サクラエディタ v2.3.2.0 32bit DEBUG
リリース版 | サクラエディタ v2.3.2.0 32bit

64bit

デバッグ版 | サクラエディタ v2.3.2.0 64bit DEBUG Alpha Version
リリース版 | サクラエディタ v2.3.2.0 64bit Alpha Version

現状のウィンドウタイトルでのバージョン表記

32bit

デバッグ版 | sakura(デバッグ版) 2.3.2.0
リリース版 | sakura 2.3.2.0

64bit

デバッグ版 | sakura(デバッグ版)(Alpha Version) 2.3.2.0
リリース版 | sakura(Alpha Version) 2.3.2.0

---

改めて提案する開発中のバージョン表記

32bit

デバッグ版 | SAKURA editor 32bit DEBUG 2.4.0.xxxx-dev
リリース版 | SAKURA editor 32bit 2.4.0.xxxx-dev

64bit

デバッグ版 | SAKURA editor 64bit DEBUG 2.4.0.xxxx-dev Alpha Version
リリース版 | SAKURA editor 64bit 2.4.0.xxxx-dev Alpha Version

m-tmatma さんに質問です

1. SAKURA editor 2.4.0.xxx がリリースされるまでの開発版は
   SAKURA editor 2.3.99.xxxという事でしょうか？
2. SAKURA editor 2.4.1.xxx がリリースされることになってそれまでの開発版は
   SAKURA editor 2.4.0.99.xxxという事でしょうか？

[m-tmatma]

2.4.0.xxx がリリースされたら、
開発版 (master) は 2.4.99.xxx になる認識でしたが
master は 2.4.1 系のままにした方がいいのかな？
今後、リリース管理をどうやっていくかに影響を受けますね。

[KENCHjp]

そうなんすよね。リリース直後に次のリリースバージョン番号なんにするかは決まってない状態なんすよね。

[KENCHjp]

なので次のバージョン-devってできないんですよね。
99もいいですが、間をきざめなくなりますしね。。。

[arigayas]

今開発中のバージョンは2.4.0で、(2.4.0に対する修正版がない場合、)
その次は2.5.0になるのかなぁ？と勝手に思ってますが、
早めに両方(次のリリースバージョン番号と次の次のリリースバージョン番号)、決めた方が良い気がします。

このissueにラベルが無いので付与していただけたらうれしいです。

[KENCHjp]

次回リリースで何を含めるかで、次のリリースのどこを上げるかを協議するようにしようと以前議論しました。
その時に大々的な修正を織り込めるかどうかはリリースするときにしか決められないので、リリース直後に次のバージョンは決めにくいかなっていうのが今の運営方針かなと。
リリース番号決めたとしても、超特急の不具合対応が必要となった場合には次回のリリースの前に緊急リリースが入るかもしれません。

また、今は自動的に、末尾はビルド番号にしようと一度決めました。
「2.3.0.65536」とかになるかもって、話しました。
次は目玉として「x64対応」にしようかということで「2.4.0.x」にしようかと思ったのですが、
いったん軽微でもリリースしましょうって雰囲気なので「2.4.0」でなくてもいいのかなとも思っております。
#71

こうなると、以前 @kobake さん言ってたように、リリースいったんした後に、
例えば「2.3.2.x」をリリースしたら、「2.3.3.x」にバージョン番号決めて奇数は開発中バージョン、ある程度まとまったら「2.3.4.x」にするのか「2.4.0.x」にするかをその時のリリースの時に決めるって方法もあるやも。

[ds14050]

次は目玉として「x64対応」にしようかということで「2.4.0.x」にしようかと思ったのですが、いったん軽微でもリリースしましょうって雰囲気なので「2.4.0」でなくてもいいのかなとも思っております。

その後サポート OS が変わったので 3 系にするのがいいと思っています(しかしそれは別の話)。

[m-tmatma]

こういうのはどうでしょうか? (TortoiseSVN 方式ではないです。Subversion 方式です。)

1. 準備
   1.1. master を 2.4.0.yyy-dev にする
   1.2. tag なしビルドでは -dev をつけるが、tag のビルドでは -dev をつけないようにビルドバッチおよびソースを変える。
2. 2.4.0 のリリース
   2.1. 2.4.0 のリリースを決めたら release/2.4.x のbranchを作成する
   2.2. master を 2.5.0-yyy-dev にする
   2.3. ver2.4.0 のタグを付けて、ver2.4.0.yyy をリリースする
   (1.2 によって -dev はつかない)
   2.4. release/2.4.x の中のバージョンを 2.4.1.yyy-dev にする
3. 2.5.0 の開発
   3.1. master で 2.5.0-yyy-dev に対して開発を続ける
4. 2.4.1 の緊急リリース
   4.1. なにか緊急にリリースする件が発生したら release/2.4.x に対して PR を投げて修正する
   4.2. ver2.4.1 のタグを付けて、ver2.4.1.yyy をリリースする

※ release/2.4.x と release から始まるようにしているのは共通の prefix をつけることで
GitHub の branch 保護の設定を一度やったらいいようにするためとリストアップしたときに
グループ化するためです。
※ 2.4.x の x はこのbranchが 2.4.0, 2.4.1, 2.4.2 ... とリリースされていく元になる
branchという意味で、可変の値を表しているわけではないです。

Subversion での具体例 (この場合 1.9.x)
http://svn.apache.org/repos/asf/subversion/branches/1.9.x/

[k-takata]

※ 2.4.x の x はこのbranchが 2.4.0, 2.4.1, 2.4.2 ... とリリースされていく元になる
branchという意味で、可変の値を表しているわけではないです。

それならば、release/2.4 でいいような気がします。

[m-tmatma]

それならば、release/2.4 でいいような気がします。

subversion の世界では一般的なので 2.4.x と提案しました。
git の世界ではあまり一般的ではないですか?

こういうのはどうでしょうか? (TortoiseSVN 方式ではないです。Subversion 方式です。)

なにか上記に限らずおすすめの運用方法はありますか?

[arigayas]

KENCHjp さんラベル付与していただきありがとうございます。

GitHub に移行して最初のリリースバージョン番号が2.4.0にしてリリース作業を経験して
x64版＆サポートOS変更が2.5.0になるのも悪くない気がします。

2.4.0 リリース以降は 2.XX.0 の XX の部分の数字を1上げていくだけで良いと思ってます。
で将来的に リリースが続いて 2.99.0 の次が 3.0.0 になったらそれなりのニュースになると思いました。
100回マイナーリリースされればメジャーバージョンを上げる理由に十分なると思いますし。
ちなみに3ヶ月に1度のリリースの計算(あと97回？)だと24年後になりますがw

[m-tmatma]

#713 で 2.4.0 の開発版にあげる PR を投げました。

[m-tmatma]

#713 をマージしたのでこれから master は 2.4.0 の dev 版になります。

[arigayas]

@m-tmatma さん作業お疲れさまです。
これで2.4.0がリリースされるまでは 2.4.0 の dev 版というバージョン表記になりました。

32bit

64bit

2.4.0がリリースされた後の開発中バージョン表記は、
2.？.？の dev 版というバージョン表記が継続されることになったんですよね？
理解が追いついていない(汗)

[m-tmatma]

↑ そこは未定です。

[m-tmatma]

#685 (comment)
のメッセージは表示上は 3 days ago になってるけど、
通知メールは、さっき来た。あれ？

[arigayas]

同じく昨日と一昨日サクラエディタ関係のメールはGitHubから来てませんでした。

[arigayas]

2.4.0がリリースされた後の開発中バージョン表記は、
2.？.？の dev 版というバージョン表記が継続されることになったんですよね？

↑ そこは未定です。

未定なら、リリース版以外のバージョン表記にdevという文字が必ず入るように
今後はするって決めるのは、いかがでしょうか？＞皆様

[m-tmatma]

未定なら、リリース版以外のバージョン表記にdevという文字が必ず入るように
今後はするって決めるのは、いかがでしょうか？＞皆様

ちょっと勘違い。2.？.？ の部分の話かと思いました。
たぶん、 devという文字が入るのは決まっていると思います。

[arigayas]

確認です。

1. リリース版以外のバージョン表記には、devが入る。
2. 次のバージョンのバージョン名は、2.4.0 になる。
3. 2.4.0 の次のバージョン名は、未定である。
4. 32bit版か、64bit版かわかるように明記する。

という認識であってますよね？

次のバージョン名以外に決める事がある気もするしない気もする(汗)

個人的に気になっているのは、
バージョン情報とウィンドウタイトルでのバージョン表記が一致してないことですが
あとで暇な時にissue登録しますね。

[arigayas]

残りは2.4.0の次のバージョン名だけだと思うのでもう閉じても良いでしょうか？

[KENCHjp]

とじやす！

[KENCHjp]

あ、バスの停車ボタン押しちゃった感。。。
ごめんなさい。