v2.4.0 beta pre-release 確認issue

[KENCHjp]

72 よりひとまず成果物作成には問題がなさそうなので、betaリリースにかかろうかと思います。

前Issueで残件が、

• [x] Webも更新する -> https://github.com/sakura-editor/sakura-editor.github.io/issues/48

後何かありましたらこのIssueへ連携してください。

[KENCHjp]

チェンジログ、エラーでてるかな？ https://ci.appveyor.com/project/sakuraeditor/changelog-sakura/history 7日まえぐらいから。

[takke]

どうやら Faraday という HTTP クライアントライブラリ が faraday-0.15.4 -> faraday-0.16.0 とバージョンが変わってしまってエラーが起きているようですね。

バージョン固定できるのかな。

[takke]

取り急ぎ https://github.com/sakura-editor/changelog-sakura/issues/26 を立てておきました。

[takke]

CHANGELOG.md が生成されない件、直りました。 https://ci.appveyor.com/project/sakuraeditor/changelog-sakura/builds/27871759

スナップショットを更新しておきました。 https://github.com/sakura-editor/sakura/wiki/CHANGELOG.md%E3%82%B9%E3%83%8A%E3%83%83%E3%83%97%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88

alpha1 からずいぶんと色んな更新が入っていますねー。

[berryzplus]

alpha1 からずいぶんと色んな更新が入っていますねー。

アプリ(=サクラエディタ)の機能に影響がある更新はかなり少ないんですけどね。

影響内容が分かりやすい変更（機能追加とか速度改善とかの大規模変更）を優先するか、 変更内容が分かりやすい変更（誤字訂正とかの小規模変更）を優先するかで迷いがあって、 ここ最近は「変更内容が分かりやすい」を重視していた結果の産物だと思っています。

changelogには、影響内容が分かりやすい変更をたくさん書きたいんですけどね :smile:

[KENCHjp]

@takke さん、素早い対応ありがとうございました。 じゃあ、週末頑張ってみるか。 Webどこまで直すかと、Gitまたしばらく触ってないので不安（そこ？） @m-tmatma さんリアルお忙しい感じかな。

[KENCHjp]

まだ、いったんベータのつもりですが、次期バージョンは、v2.4.1でいいっすよね？ 気が早い話題ですが、これもリリース手順の一環で、正式リリース後、開発中バージョンをdev-2.4.1にしたほうがいいのかなと。

[KENCHjp]

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

手順書に従いリリースしてます。 https://github.com/sakura-editor/sakura/wiki/%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E6%99%82%E3%81%AB%E3%82%84%E3%82%8B%E3%81%93%E3%81%A8

以下何点か確認です。

1. 「 GitHubのWebのUIで、Settingsからブランチの保護設定を行います(管理権限が必要) 」この手順はSettingでワイルドカードでプロテクトされるようなので不要？
2. 「help\sakura_RESOURCE\HLP000001.html を変更する」これ_RESOURCEはresに変わってるでよいでしょうか？
3. 「自分のリポジトリに push する」おっつ、Gitわかってればなんのことはないでしょうが、ここまできて、自分のリポジトリにpushするのハードルが高くて（そこ？(笑)）結局、自分のリポジトリに本家forkして、ローカルにcloneして、２つのファイルコピーしてpushしてから、PR飛ばしました　←　今ここです。

[beru]

2. 「help/sakura/_RESOURCE/HLP000001.html を変更する」これ _RESOURCE は res に変わってるでよいでしょうか？

実際のフォルダ名は変わっていますね。ちょっと経緯をしっかり覚えていないので追ってみました。

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

で変更されました。

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

に変更理由とかが書かれてます。

[KENCHjp]

@beru さん了解です！

[KENCHjp]

https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta

リリースと起動確認しました。 ベータ版なので、ここまででいいでしょうか？ 本気リリースの時にWebとChangelog修正でいいのかなと。

本気リリースの時は、このブランチをさらに本気リリースにブランチする？＆マスターのバージョン番号を2.4.1にする感じですかね？

[KENCHjp]

とりあえずここまでのWiki修正しました。 https://github.com/sakura-editor/sakura/wiki/%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E6%99%82%E3%81%AB%E3%82%84%E3%82%8B%E3%81%93%E3%81%A8

[takke]

お疲れ様です！

3.のほうは追記いただいた通り、fork 済リポジトリで作業する前提でした。

1.も設定変更済なので追記いただいた通りだと思います（実際に手を動かしてはいないので未確認ですが。。）

[KENCHjp]

このbetaで致命的な不具合なければリリースに入ろうと思います。（既存不具合は許容で） なんかあれば再リリースしましょ(笑)

[KENCHjp]

ワクチン系ソフトのホワイトリストに申請しとかないと検疫されちゃうっすね。。。

[KENCHjp]

某社の誤検知報告のページが英語。。。

[KENCHjp]

beta→正式リリースするときですが、特に不具合なければ、betaの版から、ブランチして、修正対象ファイルファイルを修正して、ＰＲだして、正式タグ打ちって感じでいいすかね？ 不具合あったら、masterで修正して、再度beta作成かなと。 betaに対して修正コミット重ねてmasterにマージでもいいのかもしれませんが。

[KENCHjp]

@berryzplus さん、重荷でなければ、Adminビット立たせていただいてもいいでしょうか？ @m-tmatma さんご多忙の様で、私がシングルポイントになるのは避けたいなと思っておりまして。。。

[arigayas]

サクラエディタふぁんくらぶ part18 [無断転載禁止]©2ch.net https://egg.5ch.net/test/read.cgi/software/1495286392/820 同梱のbregonig.dllを4.20に更新しないのはなぜ?

ツッコミがありました。

[KENCHjp]

ツッコミがありました。

@arigayas さん連携ありがとうございます。手順書トレース中なので、手順漏れがあれば合わせて修正しようと思います。

ご報告いただいたdllはリリース時に最新を同梱するよりも開発エンハンス中にコミットしていくほうが良いような気がします。

別Issue立ててコミットですかね、今回のv2.4.0ではとりあえず先送りかな。

ただ、他にもこういう同梱物漏らさないようにしないとダメですね。 意志がないと漏れていく。

[arigayas]

インストーラーの同梱物(外部DLL)ってbregonig.dll以外に何があるんでしょうか？ 複数あるなら自動的に最新版を取得する仕組みを何かしら作った方が漏れが少なくなるかもしれませんね。

[berryzplus]

@berryzplus さん、重荷でなければ、Adminビット立たせていただいてもいいでしょうか？ @m-tmatma さんご多忙の様で、私がシングルポイントになるのは避けたいなと思っておりまして。。。

いま気付きました。最近の通知はPR以外未読スルーだったので（ﾏﾃ

負担的には問題ないっす。 Adminする人が誰もいなくなると困る気がするので。

本当は みんながやりたいポジション にしときたいですね。 ダチョウ倶楽部の「持ちネタ」じゃないんだから・・・。

[berryzplus]

ご報告いただいたdllはリリース時に最新を同梱するよりも開発エンハンス中にコミットしていくほうが良いような気がします。

bregonig.dll の更新をなんでしないか？については、以前 PR のレビューでツッコミ入れてました。 ⇒ https://github.com/sakura-editor/sakura/pull/787#issuecomment-464372114

PRのその後の進展がない状態なので止まってる感じです。 基本的に先行PRのやり方を尊重する感じにしてる都合、同テーマの改善を同時に出しづらい傾向にあります。もしかすると、長期間放置の「刈り取り」を検討したほうがよいのかも。

別Issue立ててコミットですかね、今回のv2.4.0ではとりあえず先送りかな。

先送りで構わないと思います。 更新内容ちゃんと見てませんが、bregonig.dll の更新はタイミング的に spectre軽減策絡み だと思っています。(つまり、具体的なバグを修正するわけではない更新だと思っています。)

インストーラーの同梱物(外部DLL)ってbregonig.dll以外に何があるんでしょうか？

すでに入ってる同梱物

• bregonig.dll
• ctag.exe … universal ctag というプロジェクトの成果物らしいです。

入れたいという話があった同梱物

• diff.exe … 同梱しても良くね？という話が出た気がします。
• icu4c … 同梱するのは無理じゃね？という話をしてます。

複数あるなら自動的に最新版を取得する仕組みを何かしら作った方が漏れが少なくなるかもしれませんね。

なんか前にあった気がします。 ああ、SakuraDownのvb6プロジェクトをどうにかするという話があったような・・・。

• vb6⇒.NETの移行
  • 必要なもの
  • Visual Basic 6.0。
  • Visual Basic.NET 2005 or 2008(Express可)。
  • プログラムで利用している ActiveX があれば、そのランタイム。
  • 上記すべてを稼働できる状態のPC(仮想端末可)。　←　これがないｗ
  • 作業方法
    1. Visual Basic 6.0でプロジェクトを開く。
    2. プロジェクトをデバッグ実行する。
       • デバッグ実行できなければ環境整備やり直し...orz
    3. Visual Basic.NET でプロジェクトを開く。
    4. 変換ウィザードが出るので「次へ」で進めて「完了」する。
       • ここまで進めた状態からなら、環境整備は不要(vs2017で作業可)。
    5. Visual Basic.NET でビルドする。
       • 運が良ければ一発でビルドが通る。
       • 運が悪ければビルドが通らないのでコード修正をする。
    6. 「エラー一覧」のエラーがなくなるまでコード修正をする。
    7. 「エラー一覧」の警告は無視していい場合とダメな場合がある。

SakuraDown 的なものを Electron(=Javascript) で書いて自動更新をサポートしたら、周辺ツールの作成を手伝ってくれる人が増えるのかも・・・。

[KENCHjp]

@berryzplus さんどもです。で今sakura-admins見たらすでに入ってますね（あれ？） 失礼しました。

ほかに設定するところがあれば連絡をば。

[KENCHjp]

失礼しました、People画面でrole設定がありました、Ownerに変えました。

[k-takata]

universal ctags は、2019-10-03/70b44e7d 以降、できれば 2019-10-23/26d41bb9 以降に更新した方がよいです。

• 2019-10-03/70b44e7d: タグ内のファイルパスの区切り文字を \\ から / に変更。Exuberant ctagsとの互換性が落ちていたのが改善されたはず。
• 2019-10-23/26d41bb9: ctagsを複数同時に起動すると、まれに一時ファイルのオープンに失敗するバグを修正。

(2019-10-03/70b44e7d より前のu-ctagsで、サクラエディタがサブディレクトリ内のファイルをちゃんと開けていたのか疑問…)

あと、 https://github.com/sakura-editor/sakura/blob/master/installer/externals/universal-ctags/README.md#%E5%8F%96%E3%82%8A%E8%BE%BC%E3%81%BF%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA ここのソースコードへのリンクですが、universal-ctags/ctags-win32 のソースコードだと、ビルド用のスクリプトが含まれているだけになってしまいます。リンクを載せるのであれば universal-ctags/ctags の該当コミットへのリンクに変えた方がよいでしょう。(タグ名の / 以降が universal-ctags/ctags のコミットIDです。)

[k-takata]

更新内容ちゃんと見てませんが、bregonig.dll の更新はタイミング的に spectre軽減策絡み だと思っています。(つまり、具体的なバグを修正するわけではない更新だと思っています。)

bregonig.dll 4.20 のメインの更新内容は Unicode 11.0 の対応です。 （今は既に令和対応の Unicode 12.1 が出ていますが…） あとは細かなバグ修正で、spectre対応は特に何もしていません。

[KENCHjp]

ホームページ修正の所をちゃんと追いかけ始めたのですが、チェンジログをこのタイミングでプログラム本体側リリースブランチのヘルプに取り込んで、それをホームページ側のヘルプへも反映って流れがひとまずよさそうですね（手動運用） プログラム本体側リリースブランチから、masterへはリリース後に反映って感じかな。バージョンを一つ上げて。 Git不慣れなのでご意見あれば。

とりあえずリリース作業ではプログラムロジックやプラグイン系（同梱物）には手を付けない（動作に影響がでない）方針で。

[KENCHjp]

画像の差し替えもやっちゃいますかね。

[KENCHjp]

チェンジログってmdなんすよね。 2.2.0.0からのチェンジログになっているので、個々のファイルになっているのをこれ一つにしたいかなと思いますが、md->htmlに変換しないとヘルプにいれられないっすね。 なんかいい手てあります？ appveyorでmdとhtml生成してくれるのがよさそうですが、今回は手動でも可。

[KENCHjp]

pandocってのがメジャーなのかな。appveyorで動いたらいいなぁ。。。

[takke]

チェンジログってmdなんすよね。 2.2.0.0からのチェンジログになっているので、個々のファイルになっているのをこれ一つにしたいかなと思いますが、md->htmlに変換しないとヘルプにいれられないっすね。 なんかいい手てあります？ appveyorでmdとhtml生成してくれるのがよさそうですが、今回は手動でも可。

ホームページ側のヘルプの変更履歴の話ですよね？ であれば、https://sakura-editor.github.io/help/HLP000009.html から 「変更履歴(2019-03-27〜)」として https://github.com/sakura-editor/sakura/blob/master/CHANGELOG.md にリンクを貼ればいいかと思います。

[KENCHjp]

にリンクを貼ればいいかと思います。

なるほど、ネット前提ってことですね。一瞬考えてローカルにあった方がいいかなとおもったんですけど、使う上で変更履歴は確かにいらないっすもんね。

異論なければ、その方向にしようとおもいます（そしたらこの件ホームページも修正不要になりそうだし）

[KENCHjp]

あ

ホームページ側のヘルプの変更履歴の話ですよね？

editor側のも一緒にしようと思ってます。

[KENCHjp]

忘れないうちに覚書「ヘルプ修正では更新日も修正する。」旨Wikiの手順書を修正する。 ・・・なので、betaはヘルプをもうちょっと修正します。

[KENCHjp]

ヘルプに手を付け始めたら、もろもろ直さないといけなさそうなので、いったん最低限だけ修正して本体側を改めて修正しようかと^^;

[KENCHjp]

この後、このベータ版のブランチrelease/v2.4.0-betaを正式リリースrelease/v2.4.0へブランチ作って、リリースモジュール作ろうかと思います。

リリース後、メイン側のバージョンをv2.4.1にしてヘルプの修正を行う感じでおりますがご意見いただければ。 後はオンライン側のヘルプへの反映ですね。

[KENCHjp]

beta2をrelease/v2.4.0-betaブランチの中でタグつけしてリリースしました。 https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta2

んでダウンロードカウンターはブランチ単位になるのかな。。。 ↓これの書き方よくわからず・・・リリースはやっぱりタグじゃなくてちゃんとブランチしろってことなのかな。。。 ![Github Releases v2.4.0-beta2](https://img.shields.io/github/downloads/sakura-editor/sakura/v2.4.0-beta/total.svg "v2.4.0-beta2")

[k-takata]

んでダウンロードカウンターはブランチ単位になるのかな。。。

タグ単位（リリース名単位）じゃないのかなあ？ブランチ名とタグ名を同じにするといろいろ混乱するので同じにするのは避けるようにしています。

[berryzplus]

いまさらながら・・・

↓これの書き方よくわからず・・・リリースはやっぱりタグじゃなくてちゃんとブランチしろってことなのかな。。。 ![Github Releases v2.4.0-beta2](https://img.shields.io/github/downloads/sakura-editor/sakura/v2.4.0-beta/total.svg "v2.4.0-beta2")

なんだろう？と思って調べてみました・・・が、見付かんなかった...orz GitHub Release の [downloads@v2.4.0-beta2] のリンクアイコンのソースがそうなってるんですね。

たぶんこうかな？と思った内容からして「あれ？」と思う点が一つ。

• ![Github Releases v2.4.0-beta2](https://img.shields.io/github/downloads/sakura-editor/sakura/v2.4.0-beta/total.svg "v2.4.0-beta2")
• ![リリース名](https://~固定~/sakura-editor/sakura/ブランチ名/total.svg "画像のaltテキスト")
  • 引用のURLだと「ブランチ名」にあたる部分がbetaになってます。（beta2じゃない)

この辺は @m-tmatma さんとか詳しそう。

[berryzplus]

よく考えてみたら自分で試せるようになってたので変えてpreviewしてみたら、 637⇒13になったのでビンゴっぽいです。

[KENCHjp]

確認あざす。最初私そこbeta2にしたらエラーになったんすよね。なんかタイミングがあるのかも？ とりあえず修正しました。良かった。

[KENCHjp]

https://github.com/sakura-editor/sakura/issues/1109 バグ報告ありです。

[KENCHjp]

フットワーク遅くてすいません。 Beta3リリースしました。 https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta3

@m-tmatma さんからご指摘ありましたが、リリース用の修正（バージョン情報等の最低限の修正）と、それ以外のヘルプ等の修正は分けたほうがよかったですね（すいません、今回そこまで細かくできてませんでした）。

これで、しばらく寝かせて致命傷なければBeta3->リリースへ進みたいと思います。 年明けっすかね。

[KENCHjp]

あ、あと旧版(2.3.x.x)のIniファイルがあると、ツールバーのアイコンが消えちゃう気がします（すいません細かく調べれてませんが、再現テストして確認できたらIssue立てます。 上書きインストール時にこまるかもですが、私ツールバーつかってないんすよねｗｗｗ

[KENCHjp]

次期リリースの時のブランチの作り方は、最初にリリース名でブランチ作成、 今回で言うと、 release/v2.4.0 でタグを、「release/v2.4.0-beta1」で打って、 不具合等あれば、master側で修正後、リリースブランチrelease/v2.4.0へマージして 「release/v2.4.0-beta2」のタグ打ち。 以降何かあればmaster側の修正をマージしてbetaの版数を増やすを繰り返し、 最後にヘルプ他リリース日等を修正して「release/v2.4.0」のタグ打つって感じでどうでしょう。

[KENCHjp]

リリース後にやること（覚書）

• Masterのバージョンを2.4.1にする。
• LICENSE ファイルのコピーライトを2020年にする。

[k-takata]

でタグを、「release/v2.4.0-beta1」で打って、

タグには release/ は含めないですよね？

[KENCHjp]

タグには release/ は含めないですよね？

お、そうですねm(＿＿_)m 突っ込み感謝。

[m-tmatma]

• LICENSE ファイルのコピーライトを2020年にする。

これはリリース前にやったほうがいいと思います。