Closed KENCHjp closed 5 years ago
https://github.com/sakura-editor/management-forum/issues/52#issuecomment-477000416
転記。
sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Exe.zip
をダウンロードしましたが
このファイルをフォルダ名にして展開すると
R:\sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Exe\sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\EXE\sakura.exe
と sakura.exe
までのパスが137文字あって長いのは少し対策が必要じゃないか?と思いました。
R:\sakura-v2.4.0-alpha1-Win32-Release-Exe\sakura-v2.4.0-alpha1-Win32-Release\EXE\sakura.exe
になったらちょっとマシかな?と思いました。
ちなみにインストーラーだと
R:\sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Installer\sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\Installer\sakura_install2-4-0-1699-x86.exe
EXE ファイルまでのパスが137文字あります。
早速ありがとうございます。
EXE の ZIP が Installer よりもデカイ(18.6MB)のが気になっていまして、そのままアップロードしていいのか躊躇していました。
sakura.pdb や sakura_lang_en_US.pdb は(debugビルドはともかく)Releaseビルドには不要かなと思うのですがいかがでしょうか。
R:\sakura-v2.4.0-alpha1-Win32-Release-Exe\sakura-v2.4.0-alpha1-Win32-Release\EXE\sakura.exe
になったらちょっとマシかな?と思いました。
私もリリース版は sakura-v2.4.0-alpha1-Win32-Release-Exe.zip くらいにリネームしてアップロードでもかまわないと思います。Artifacts へのURLも貼っていただいているのでどのビルドかは追跡できると思いますし。
https://github.com/sakura-editor/sakura/pull/263
これが治ってない気がします。 うち的にはこれキラーコンテンツなのでどなたか検証対応をお願いします。
sakura.pdb や sakura_lang_en_US.pdb は(debugビルドはともかく)Releaseビルドには不要かなと思うのですがいかがでしょうか。
私も思ったのですが、一旦そのままあげてみました。 releaseビルドに必要なければ、削りたいですね。
sakura.pdb や sakura_lang_en_US.pdb は(debugビルドはともかく)Releaseビルドには不要かなと思うのですがいかがでしょうか。
Releaseビルドを実行中に起きたエラーを調べるには、Releaseの .pdb も必要だと思います。ただ、同じ .zip ファイルに入れるべきかは疑問です。ついでに、sakura-doxygen.chm/chi も別zipでいいのではないかという気がします。 なお、sakura_lang_en_US.dll には実行コードがないので sakura_lang_en_US.pdb はRelease/Debugともに不要だと思います。
ファイル名の長さおよび何を梱包するかについては、ci系手を入れるのが工数かかるようであれば(またはセンシティブであれば)、一旦手動対応でも構わないかなと思っています。 何を梱包するかだけの議論でいいかと思うので。 最悪インストラーのみ公開でも構わないかなと。
sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Installer.zip sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Exe.zip
このこらの中のパスが、 \sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\EXE\ \sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\Installer\ がついてるので、まるっと取ってて直下をzip化してもいいかもですね。
インストーラーをWindows10(32bit)で、新規インストールアインインストールの動確しました。
備忘録 https://github.com/sakura-editor/sakura-editor.github.io こっちもv2.4.0リリース用のブランチ切る。
これが治ってない気がします。 うち的にはこれキラーコンテンツなのでどなたか検証対応をお願いします。
これは新規インストールのみです。 アップデートインストールでは、設定値は変更されないので。
これは新規インストールのみです。
新規インストールしたつもりです。
C:\Program Files\sakura
このsakuraフォルダと、
C:\Users\
このsakuraフォルダが無いのは確認して新規インストールしたのですが、 他にありますでしょうか?
起動して、
C:\Users\
ここにiniファイルが出来上がってるのを確認して一度落として、iniファイル削除して再度たちあげてもみたのですが。
32bit os ですか? 64bit os だとアプリフォルダが違います。
↑ 書いてた。
32bit osです。 VirtulaBoxで32bitのまっさらな環境作って確認中。
sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Installer.zip sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release-Exe.zip
このこらの中のパスが、 \sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\EXE \sakura-tag-v2.4.0-alpha1-build1699-2582c34c-Win32-Release\Installer がついてるので、まるっと取ってて直下をzip化してもいいかもですね。
これは https://github.com/sakura-editor/sakura/pull/114#issuecomment-396964052 で対応したものです。
パスを短くするのは zipartifacts.batをちょこっと変えるだけです。 ただ、私は今日は時間は取れないです。
今日リリースすることにこだわらなくてもいいんじゃないかとは思ってます。 見つかった問題を対処してからリリースする方がいいと思います。
すいません、今日releaseにはこだわってないです。 @takke さんが頑張っていただいたので、私もやれる範囲で、一通りreleaseまでやってみようかなって思って手を動かしてみましたが、 まだalpha版なので、こっから1weekぐらいみんなで埃叩いて再来週ぐらいリリース出来たらなってイメージです。 4月中でもいいかなっと。
もういっそ新元号にあわせてもいいかなとかか。
https://sakura-editor.github.io/download.html
こちらのページの更新もリリース作業に加えるのはどうでしょうか?
https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-alpha1
にダウンロード数のカウンタつけました。
こんな感じの指定です。
![Github Releases v2.4.0-alpha1](https://img.shields.io/github/downloads/sakura-editor/sakura/v2.4.0-alpha1/total.svg "v2.4.0-alpha1")
パス名を短くする PR https://github.com/sakura-editor/sakura/pull/815 を作成しました。 ZIP 内部のフォルダ名に関して、こうしたほうがいいとかあったらコメントください。
ファイル名の長さおよび何を梱包するかについては、ci系手を入れるのが工数かかるようであれば(またはセンシティブであれば)、一旦手動対応でも構わないかなと思っています。
https://github.com/sakura-editor/sakura/pull/815 が終わったら PR 投げます。
@m-tmatma さん
sakura-editor/sakura#815 が終わったら PR 投げます。
了解です!
あと、https://github.com/sakura-editor/sakura/milestone/1 の扱いを考える必要があります。
https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-alpha1 を作成していますが、
alpha1 ~ 正式な v2.4.0 までのバージョンの間にいくつか変更が入ると思いますが、 どの修正が alpha1 ~ 正式な v2.4.0 の間に入ったか、わかるようになんらかの形で 管理したいです。
@beru さん
こちらのページの更新もリリース作業に加えるのはどうでしょうか?
もち!
@m-tmatma さん
>どの修正が alpha1 ~ 正式な v2.4.0 の間に入ったか、わかるようになんらかの形で 管理したいです。
ですよね。 正式なv2.4.0とalpha1のタグ付けの間は、Add CHANGELOG.md に再度反映されるかなって考えております。 もしくは、alpha1はあくまで検証で、2.3.0~2.4.0のCHANGELOGでもいいのかなとか。
あと、https://github.com/sakura-editor/sakura/milestone/1 の扱いを考える必要があります。
名前を "next release" から v2.4.0 に変更しました。
https://github.com/sakura-editor/sakura/milestone/1 にマイルストーンが設定されているもので まだ open のものがいっぱいある。
releaseのzipファイル作成と同時にmd5ファイルも生成してあると捗りますね。
certutil -hashfile D:hoge.exe MD5
はまるのは最後のハッシュ アルゴリズムがちゃんと大文字じゃないとダメってところ・・・
一応「カンバン」も作ってありますが、「カンバン」を運用するのも二重メンテな感じがするので、今後はこういうIssueで廻した方がいいかなと、思い始めております(ほぼ独り言)
忘れないように書いておきます。 正式リリースのときは changelog.md を wiki に貼り付けるのも必要です。
releaseのzipファイル作成と同時にmd5ファイルも生成してあると捗りますね。
certutil -hashfile D:hoge.exe MD5
はまるのは最後のハッシュ アルゴリズムがちゃんと大文字じゃないとダメってところ・・・
これはローカル生成ですか? それならこれも appveyor で自動化したい
これはローカル生成ですか?
alphaは手動ですが自動化したいっす。
appeyor で sha 系のハッシュをすでに生成してたような気がします。
忘れないように書いておきます。 正式リリースのときは changelog.md を wiki に貼り付けるのも必要です。
これって CHANGELOG.mdスナップショット のことですか?それとも古い wiki ですか? (リリース手順に追記しようと思いまして)
appeyor で sha 系のハッシュをすでに生成してたような気がします。
各々のファイル単位でしたっけ?
@KENCHjp さん
備忘録 https://github.com/sakura-editor/sakura-editor.github.io こっちもv2.4.0リリース用のブランチ切る。
@beru さん
https://sakura-editor.github.io/download.html こちらのページの更新もリリース作業に加えるのはどうでしょうか?
いずれも同じように Web の更新のことをさしてますよね。 取り急ぎ、リリース手順のWiki に追記しました。
Webだしわざわざv2.4.0リリース用のブランチ切らなくても、、と思ったんですがダウンロードページはだいぶ古いので全面的に書き換える必要があるんですね。 Web の更新は https://github.com/sakura-editor/sakura-editor.github.io/issues/48 を立てたのでこちらで議論したいです。
2.4.0 の alpha 1 用のページ、alpha 2 用のページ、正式版のページとリリース毎に作ったらいいと思います。
2.4.0 の alpha 1 用のページ、alpha 2 用のページ、正式版のページとリリース毎に作ったらいいと思います。
えーっと、これは wiki の CHANGELOG のことですか?
appeyor で sha 系のハッシュをすでに生成してたような気がします。
https://github.com/sakura-editor/sakura/blob/master/appveyor.md
ここに説明ありましたね。 sha256.txtってファイルが出来るように見えるのですが、appveyorの成果物から見つけられず・・・
2.4.0 の alpha 1 用のページ、alpha 2 用のページ、正式版のページとリリース毎に作ったらいいと思います。
えーっと、これは wiki の CHANGELOG のことですか?
そうです。 そうすればどの alpha でどの機能をいれたか追跡可能でかつ、生成を 自動かできて楽かと思います。
* md5ファイル生成も appveyor で自動化したい
コマンドラインでやる方法はいっぱいあるけど、ハッシュだけ出力はないのだろうか? https://www.atmarkit.co.jp/ait/articles/0507/30/news017.html
https://docs.python.org/ja/3/library/hashlib.html を使えば python でも書けるが。
https://docs.python.org/ja/3/library/hashlib.html を使えば python でも書けるが。
既存の sha256.txt は hashlib を使って calc-hash.py で生成している。
2.4.0 の alpha 1 用のページ、alpha 2 用のページ、正式版のページとリリース毎に作ったらいいと思います。 そうすればどの alpha でどの機能をいれたか追跡可能でかつ、生成を 自動かできて楽かと思います。
現状の changelog-sakura の設定だと、タグを打った時刻で区切って Issue/PR が抽出されるので、そのままでも alpha1 と alpha2 ~ 正式版のそれぞれの修正が載ることになります。
例えば Release/v2.4.0-alpha1 タグを打った後に閉じたリリース作業のPR #814 は、今朝生成された CHANGELOG.md には Unreleased すなわち alpha2 相当のところに載っています。 (https://github.com/sakura-editor/sakura/pull/814 自体は management ラベルを付けたので次回からは抽出されなくなりますけど)
CHANGELOG.md には alpha1 等は含めず、正式版の分だけ載せるほうがいいですかね。そうであれば CHANGELOG.md のコミット前の整形がもうひと手間必要になりますね。
OS標準ではいっているので、certutilつかうのがハッシュ値とるだけならいいのかなと。
sakura.pdb や sakura_lang_en_US.pdb は(debugビルドはともかく)Releaseビルドには不要かなと思うのですがいかがでしょうか。
Releaseビルドを実行中に起きたエラーを調べるには、Releaseの .pdb も必要だと思います。ただ、同じ .zip ファイルに入れるべきかは疑問です。ついでに、sakura-doxygen.chm/chi も別zipでいいのではないかという気がします。 なお、sakura_lang_en_US.dll には実行コードがないので sakura_lang_en_US.pdb はRelease/Debugともに不要だと思います。
サクラエディタ側、web 側ともに release ブランチの protect 設定しました。
このIssueで決めてた方がいい気がしてきたのですが、2.4.0リリース直後に、一旦バージョンを2.4.1にして、マジリリースしようとするときに、2.4.1でいいくのか、2.5.0にするのか再協議って運用どうでしょう。
https://github.com/sakura-editor/sakura/milestone/2 v2.4.0 以降にいれるための Milestone を作成しました。 v2.4.0 には入れないことを明示して目標スケジュールの共有に使用ください。
前のIssueが長くなってきたので新たに立てます。
https://github.com/sakura-editor/management-forum/issues/52
コメントで上げられた検討事項