https://sourceforge.net/p/sakura-editor/wiki/RepoRelease/Recent changes to RepoReleaseenSun, 21 Apr 2013 13:39:50 -0000https://sourceforge.net/p/sakura-editor/wiki/RepoRelease/<div class="markdown_content"><pre>--- v1 +++ v2 @@ -1,4 +1,4 @@ -[開発に参加したい方へ](Join)＞[Subversion]＞[リポジトリガイドライン](RepositoryManage)＞リリース +[開発に参加したい方へ](Join)＞[Subversion](Subversion)＞[リポジトリガイドライン](RepositoryManage)＞リリース # リリース # リリースはリリース担当者の判断で行う．新たな変更が入り，Commitが完了したら速やかにリリースを行うものとする． </pre> </div>novice123Sun, 21 Apr 2013 13:39:50 -0000https://sourceforge.net4cbd0e67da73dc238af8183f5f9b7c63ef549b4chttps://sourceforge.net/p/sakura-editor/wiki/RepoRelease/[開発に参加したい方へ](Join)＞[Subversion]＞[リポジトリガイドライン](RepositoryManage)＞リリース # リリース # リリースはリリース担当者の判断で行う．新たな変更が入り，Commitが完了したら速やかにリリースを行うものとする． 基本的にはtrunkへ入るコードは検証済みの物であるので，trunkの最新リビジョンをリリースする． リリース時に(リリース担当者が)行うこと * リリース用作業スペースの中身を最新にする(svn update) * バージョン番号を決める * リソースのバージョン表記を書き換えてCommit * コンパイル＆実行ファイル作成 * ソースコードをExportしてtar.bz2で圧縮． * ラベルの作成： **tags/** ディレクトリにラベルを作成する．命名規則は後述． * 実行ファイルとソースファイルをSourceForgeのFile Releaseエリアに登録． * リリースノートの作成 * 変更点のまとめ * 対応するリビジョン * 掲示板でのアナウンス 検証が不十分と思われる場合， Private branchからの大きなマージが入った場合などはβ版としてリリースしてもよい．β版と正式リリースの違いはバイナリ・ソースのリリースエリアへの登録時の記載のみである．その後検証が完了して問題がない場合でも同一の内容であれば再度のリリースは行わず， SourceForge.netのリリース名称の書き換えで対応する． 実際には微細ではある物の変更があると考えられるので，それを取り込んで正式バージョンを与える． SourceForgeに登録を行わないテスト版を公開した場合には，動作確認後に改めて登録を行う必要がある． novice123Sat, 10 Nov 2012 14:38:45 -0000https://sourceforge.netfc1bd769f3ef63e579be452dafa10014c351bbf6