リリースに関して

[m-tmatma]

リリースに関して

そろそろリリースしませんか?

以前、リリースの提案があったときに以下のコメントで反対意見を書きました。 https://github.com/sakura-editor/sakura/issues/71#issuecomment-395387472

リリースするための目玉機能がないという理由でした。

あれから、約5ヶ月経過して、マージ済みの PR は 326個にもなります。 https://github.com/sakura-editor/sakura/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged

ここらあたりでリリースしてもいいんじゃないかと思います。 (※ 64bit 対応は5ヶ月経っても完了してませんが、次以降のリリースに回してもいいんじゃないかと思います)

[m-tmatma]

ターゲットとしては 2018/12 末までに、というのを希望します。

理由は個人的な事情ですが、来年1月に転職するという事情があり、 サクラエディタに割くことのできる時間が大幅に減る見込みだからです。

もちろん、まだリリースしたくないという話でしたらそれはそれで構わないです。

[KENCHjp]

一応、カンバン立てたのは、リリースしたかったからです。 目玉は、64bit対応だったかと思います。 64bit対応のめどが立つ前にリリースしたい総意であれば、それでも私は構わないかと思います。

一度リリースの手順を回して、次回64bit対応でもいいのかなと。 そういう意味では、カンバンの中身からリリースに向けて実施するものを絞っていけばいいのかなと。

となると、リリースは32bit版のみで、対応としてはWin10のテスト実施済ってところですかね。 あとは各種エンハンス、ドキュメントがどこまで対応するかですね。

パッケージ版はおいておいて、バイナリだけって選択肢もありかもしれませんが。

[berryzplus]

本年中リリースを目標とすると色々未完了な部分が残ると思います。 ぼくはもともと暫定でもリリースしたい派なので文句はありません。

一点、アイコンを拡大描画させる修正だけは入れたいなぁ、と思ってます。 あれが入ると入らないとで高解像度環境下での使い勝手が全然違うので。

[beru]

近々リリースするとしたらどこかのタイミングで機能追加の凍結をして、機能追加のPRはリリース用の main ブランチにはマージしないようにする必要がありますね。リリースが終わるまでは。

旧バージョンのアップグレードが色々な設定で問題が無いかとか、各機能が前のリリース版と比較してデグレしていないか等のテストをした方が良いですね。ただ網羅的にテストするのはリソース的に厳しいのでバグはどうしても色々残っちゃうと思います。

以上思い付きで書きましたが何かテンプレート的な文章ですね。。

[berryzplus]

残課題整理が必要ですね。

一点、アイコンを拡大描画させる修正だけは入れたいなぁ、と思ってます。

こういう意見が他にないとも限らないと思っています。

[m-tmatma]

あと、前回リリースから何の修正が入ったかを整理するのがいいと思います。

[KENCHjp]

あと、前回リリースから何の修正が入ったかを整理するのがいいと思います。

一度、 @kobake さんが、コミットログから引っこ抜いてましたよね。

https://github.com/sakura-editor/sakura/wiki/NextRelease

[kobake]

リリースしたいあたりの時点からリリースブランチを分岐させると良いです。

そしたら、今回のリリースに入れるつもりはないけどそれ以降の後々で入れたいような機能は master 側に引き続き積んでいけば問題ないです。

個人的には「凍結」とか「残課題」とか堅苦しいことはそこまで考えなくても良いと思っています。現時点での安定板が master に入っていると仮定すればそれをリリースすれば良いじゃんくらいの気持ち。致命的なバグが master に入っていることがあるとすればその限りではありませんが。

[beru]

開発者の数が少ないので機能追加のPRを継続した場合にリリースに支障が出ないかなと少し心配でした。 まぁでもやはりソフト開発なのでレビューワーをギリギリまで追い詰める大量の差分を含んだPRを出し続ける事が大事なのかもしれませんね…。

[kobake]

PR開きっぱなしでもリリースはできますよ。そのためにブランチ切ってるので。なのでレビュアーも追い詰められる必要ないです。どうしてもリリースに入れたい機能があるのであれば、そこだけレビューがんばりましょう。

[beru]

そうですね。。リリースに集中していてレビューに割く手間が無かったら自然と放置されますね。

[kobake]

実際のところ、リリースパッケージ作成の作業最中に何かしらのPRがマージされることがあってもまったく問題ないです。どういった問題を懸念されてますか？

[beru]

リリースが近いなら機能追加より不具合修正やテストとかの保守的な作業に回った方が良いのかなと考えていました。ただ全体の方針とかそういうのは決めないでルールの範囲内で好き勝手にやった方が良いのかもしれないですね。

[berryzplus]

とりあえず、誰かが仕切りを始めるまで平常運転で構わないと思います。 みなさんの協力が必要になったら誰かが声をかけてくれるでしょう。 誰もやらんなら自分が声掛けますし。

平日の昼間っから活発に議論しない！ :smile:

[KENCHjp]

リリースが近いなら機能追加より不具合修正やテストとかの保守的な作業に回った方が良いのかなと考えていました。

新規リリースに不具合があるなら、急ぎかもしれませんが、現状の不具合は「そこにある問題」として認知してても、結局今まさに起こっていることなので、先延ばししても事態は悪化しないかなと（よくもならないけど）

みなさん「不具合」見つけるととりあえず何とかしようとしてしまう「性」はわからないでもないですが(笑)

[berryzplus]

平日の昼間っから活発に議論しない！

ちょっと失言だったかも知れません。

人それぞれ、都合のいい時間帯ってあると思うので、自由にやればいいと思ってます。 ぼくもいま比較的自由な職場ですが、あんまり他事してると怒られそうです。 羨ましい限りなのでやるなら「こっそり」な感じで。 「サクラエディタ住民、プーさんばっかかよ」と言われるのも悲しいですし :sob:

[KENCHjp]

あんまり他事してると怒られそうです。

それが普通(笑)

最近席でタバコも吸えないので普通に職場で休憩って難しいですよね。 昔はVDT休憩は１時間に１０分ぐらいしましょうってあったけどねぇ。

[m-tmatma]

あと、前回リリースから何の修正が入ったかを整理するのがいいと思います。

一度、 @kobake さんが、コミットログから引っこ抜いてましたよね。

https://github.com/sakura-editor/sakura/wiki/NextRelease

53 を作成してみました。

[berryzplus]

この話どうします？

年始は1/6まで休めるので、２～３日くらいは作業できますが。

[m-tmatma]

まずどうやってリリースするかと、あとどの機能 or バグ修正をいれるのかを考える必要がありますね。

[ds14050]

リマインダ：メールアドレス判定が壊れていることがわかっています。

[berryzplus]

リマインダ：メールアドレス判定が壊れていることがわかっています。

sakura-editor/sakura#398 を解決するために入れた sakura-editor/sakura#421 の判定が正しくないって話( sakura-editor/sakura#493 )です。

421 がmerge済みで、正しくない判定を含んでいます。

落ちない系の間違いなので「既知の問題」で残してよいと思っています。

[m-tmatma]

↑ チケット番号がリンクにならないので チケット番号の前後に半角の空白をいれていただきたいです。 と思ったけど、これは sakura 側のチケット番号だからリンクにならないんですね

[berryzplus]

とある掲示板に、ヘルプのキーワードが壊れているという報告が上がってました。 ヘルプの目次はたぶんshift-jisです。文字コードの問題なんではないかと。

[m-tmatma]

落ちない系の間違いなので「既知の問題」で残してよいと思っています。

修正するの難しいですか? そんなに時間がかからないのなら多少リリースを遅らせても修正しておきたいです。

[m-tmatma]

とある掲示板に、ヘルプのキーワードが壊れているという報告が上がってました。

チケット登録していただけますか?

[k-takata]

sakura-editor/sakura#326 はリリースまでにどうにかすべきだと思います。

[k-takata]

あとは、必要に応じて https://github.com/orgs/sakura-editor/projects/1 の整理も。 （64bit対応のチケットを除外するとか）

[m-tmatma]

https://github.com/sakura-editor/sakura-editor.github.io/issues/24 もやっておきたい

[berryzplus]

@k-takata さん

sakura-editor/sakura#326 はリリースまでにどうにかすべきだと思います。

仕様を見直す話なので、直近のリリースに間に合わせるのは難しいと思っています。

ざっくりと言うと、 ・描画位置の画面座標が欲しい人がいてマクロから取れるようにした、があって、 ・サクラエディタに元々あった桁位置を取得する機能を上書いてしまったことが問題。

内部的には「行＋桁」のことも「座標」と呼んでるので整理は大変そうです。 平成のうちに「次の次のリリース(=v2.5.0)」をしたいと考えていて、そこには入れたいです。

[berryzplus]

「年始のタイミングでリリース」というのがなんとなく流れた感じで、 やっぱり4月末くらいまで無理なんかなぁ・・・と思っているんですが、 無理にでも前倒しを目指すための(アフォな)口実があることに気付きました。

3月27日は「さくらの日」

[ds14050]

@niki さんに指摘をもらった cUnicodeBuffer 変数のシャドウイングもずっと気になっています(最初の PR にするつもりの作業中に事故が起こってそのままです)。

[berryzplus]

ああ、あのときの・・・。

コード変換については、std::codecvtをカスタムしてエラーバイト列をUnicodeの拡張16面私用領域に押し込めるプランを持っとりました。エラー処理の方法さえ確立できればcodecvtは使えると思ってたので。

std::codecvtがc++17以降非推奨となるのはご存じの通りで、他のプランを探る必要を感じています。

既存コードを活かしつつ上手い感じにまとめる作戦はないものかと思案中です。

[KENCHjp]

さて、定期リマインド。

既知の不具合は現状も変わらないから放置で、ｘ６４化はじっくりやるとして、 入れたいものをやり切って、先送りするものはいったん放置。

なんか、リリースに対して必要なのは、段取りではなくて、モチベーションな気がしてきました(笑) 機械的に３か月おきにリリースとか決めてるソフトはそれなのかも(笑)

[KENCHjp]

https://github.com/sakura-editor/sakura/issues/189

ひとまずリンク。

[berryzplus]

Xデー候補が他にないようなので、3/27リリース目標で動き始めませんか？

[KENCHjp]

異論ないです。ケツ決めて動きますか？ 逆算はデスマでありがちですが、なんか決めていったん水平線作って無理ありそうなら再考しましょうか。

今月中でリリースブランチ決めて、３月頭にα版作ってテスト、3/27リリースって感じですかね、ざっくり段取りですけど。

[berryzplus]

少なくともいっぺんα版のリリースをしときたいですね :smile: 3/27が何回目かのα版で終わってもよいくらいだと思っています。

[KENCHjp]

さ、リリースしましょうか。 もうすぐサクラが開花します。

[berryzplus]

お願いします。ドキュメントまとまってなくても雰囲気でリリースでいい気がします。

何気に、何をどうするとリリースになるか、実は分かってない気がしてきました。

[KENCHjp]

@berryzplus さん

＞何気に、何をどうするとリリースになるか、実は分かってない気がしてきました。

実は私も(笑) 今の版で一旦フリーズでいいのかしら、タグ付けからかと思うのですが。

[KENCHjp]

https://github.com/sakura-editor/sakura/issues/189 ここからするに、@jakenjarvis さん提案で、一旦pre-releaseブランチ作るですかね。

[KENCHjp]

色々と中途半端（または修正しなければならないもの）があるのかもしれませんが、 一旦目的を「リリースする」において、色々と具体的に手数ふんでみようかなと。

[jakenjarvis]

しばらく目を離していましたが、呼ばれた気がしました（笑） 開花時期にあわせてリリース素敵です！みんなビール持って全裸待機ですネｗ

[berryzplus]

未解決の問題が結構ありますが「リリースを行うことそのもの」に意義があると思っています。

3/27が「サクラの日」らしいので、そこに合わせてリリースすることにしました。（勝手に。 ※日付については単なるノリなのでズレてもよいです :smile:

ついてはこの土日で、現状の master を「とりあえずリリースする」には何をしたらいいのかを再確認したいなぁ、と思ってます。

[KENCHjp]

未解決の問題が結構ありますが「リリースを行うことそのもの」に意義があると思っています。

まったくもって同意見です。

[KageShiron]

新版公開で開発に興味を持ってくださった方向けに、ヘルプの更新などの簡単なissueを立てて置きたいですね

[KENCHjp]

https://github.com/sakura-editor/sakura/pull/813

こちらコミットされたら生成されたインストーラーとEXEをpre-releaseでアップロードする感じですかね。

https://github.com/sakura-editor/sakura/releases

タグ付けするとこの一覧に追加されるようですね。

[KENCHjp]

https://github.com/sakura-editor/sakura/issues/685

とりあえず、はっておく。

[takke]

https://github.com/sakura-editor/sakura/pull/813 の続きです。

リリース作業の手順を確認、整理しようとしています。 メモがてら書きますので少し長いですがご容赦ください。

@KENCHjp さんより

本チャンも、 AppVeyorから持ってこようと思っておりますです。個人の環境の生成物だと差異があったときに拾えないかなと思うので。

私も AppVeyor で正式リリース版も作ったほうがいいと思っています。

CDlgAbout.cpp#L193-L195 を見ると、バージョン表記を APPVEYOR_REPO_TAG_NAME によってタグから作るようになっているんですね。

https://ci.appveyor.com/project/sakuraeditor/sakura/history から探したところ、昨日私が付けたタグでビルドされていました。

この版の Artifacts を v2.4.0-alpha1 の成果物とすればいいかと思うのですが、バージョン表記は 「サクラエディタ v2.4.0.1692 32bit dev (tag v2.4.0-alpha1)」 となっています。

この " dev" を消すには sakura/githash.bat の APPVEYOR_DEV_VERSION の定義を REM 等で消せばいいんですね。

https://github.com/sakura-editor/sakura/blob/6622eb9f860b3798748bd92ae1035a66fec427f3/sakura/githash.bat#L163-L164

@m-tmatma さんのコミットメッセージにそのものズバリで書いてありました。 APPVEYOR_DEV_VERSION をコード上で常に定義するようにする (リリースブランチで手動で無効化するのを想定する) https://github.com/sakura-editor/sakura/commit/c072ba9020ec078d517663edc24d2d95b18ee8fe

というわけでまず master から分岐してリリースブランチを作り、githash.bat を書き換えてコミットして、そのコミットにタグを打つという手順なんですね。

手順まとめつつリリースブランチの作成、タグの打ち直しなどやってみます。