PATCH_RELEASE
9.88 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
パッチについて
I. 種類
・一般配布 ---- バグ修正
+
+-- 新機能追加
・一時配布 ---- 一時一般配布(全員に配布)
+
+-- 一時限定配布(特定者にのみ配布)
・永久限定配布 ---- マイクロコード限定版
というように考える。ただし、形式上(名称も)区別するのは大区分、
すなわち一般配布か一時配布か、あるいは永久限定配布か、３つの内
のどれにあたるかで区別することにする。
一般配布は通常のパッチであり、全ライセンシーに配布される。
一時配布とは、何らかの理由(実際に使ってもらって感想を聞いたり、
バグ出ししたい場合など)により、一時的に配布するものを指す。必
ずしも全ライセンシーに配布されるとは限らない。(配布対象はリリー
ス時に配布者が指定する。)
一時配布は管理上の混乱を避けるため、速やかに一般配布に移行する
こと。
永久限定配布とは、一般配布することを考慮にいれない限定配布のこ
とである。管理上の混乱を避けるため、特に他のツールやライブラリ
と完全に独立したものである必要がある。現時点では、マイクロコー
ドをゲームごとにカスタマイズしたもののみが対象になる。
II. 名称
ただし以下において、yymmdd はパッチ作成日の１週間後の日付とする。
○一般配布
patchNgyymmdd_ultra ultra 用のパッチ
patchNgyymmdd_64dd 64dd 用のパッチ
patchNgyymmdd_naudio naudio 用のパッチ
但し、これらは過去にリリースされたパッチの累積とする。
一般配布のみ、mp というツールで自動作成ができる。詳しく
は
yuichan:/disk4/patch/patchmdev2/PR/patch/README
を参照のこと。
○一時配布
patchNtyymmdd_xxxxx
過去のパッチは累積しない。(理由: このパッチが一般配付
化する前に、次の一般配布パッチがでる可能性があるから)
ただし、xxxxx はパッチの内容が分かる、４文字以上６文字
程度までの英小文字からなる文字列とする。(このフィール
ドがパッチ名の最後にあるため、５文字ちょうどにするメリッ
トはあまりないように思われる)
一般配布にするときは、必ず一般配布パッチを作り直し、(一
時配布を出したところに対しても再度)リリースし直すこと。
○永久限定配布
patchNpyymmdd_xxxxx
過去のパッチは累積しない。
ただし、xxxxx はパッチの内容が分かる、４文字以上６文字
程度までの英小文字からなる文字列とする。
＊１週間後が休日だとしても、気にせずに名前付けをする。つまり、
「980505」等の日付のついたパッチが出る可能性がある。
→１週間後の日付を生成する部分を自動化したいから。
(祝日まではちょっと...)
III. 配付方式
一般配布の場合は、下記のようになる。一時配布、永久限定配布の場合
は、できる限り同様のディレクトリ構成にするようにする。
＜SGI 版＞
-+--INSTALL.jp インストールする際の注意点のようなもの
|
+--<dist>
|
+--<doc>
以上を DAT に。
＜PC 版＞
-+--INSTALL.jp インストールする際の注意点のようなもの
|
+--<dist> 自己解凍ファイル
|
+--<doc>
以上を CDROM に。
(開発３部からのリリースとしては、メディアは問わないが、業務部にて上
記メディアに格納されて配布される)
IV. ドキュメント
INSTALL.jp(インストールする際の注意点)
文面は、最初は例えば SGI 版なら
「本 DAT を展開すると、下記のファイルが展開されます。
-+--INSTALL.jp このファイル
|
+--<dist>-+-- patchNg980201_ultra
| |
| +-- patchNg980201_ultra.dev
| |
| +-- patchNg980201_ultra.idb
| |
| +-- patchNg980201_64dd
| |
| +-- patchNg980201_64dd.dev
| |
| +-- patchNg980201_64dd.idb
| |
| +-- patchNg980201_naudio
| |
| +-- patchNg980201_naudio.dev
| |
| +-- patchNg980201_naudio.idb
|
+--<doc>--+--<ultra>--+--README.jp
| |
| +--Changefiles.jp
|
.............................
swmgr を立ち上げて dist を指定して、全ファイルをインストールし
てください。各パッチに関しては、対応する各 README.jp を参照し
てください。」
のようなものにします(PC 版では、dist の下が .exe ファイルに
なる)。以降、例えばインストール時の質問等を「FAQ」のようなもの
にするなどして、適宜追加します。
「このドキュメントは、どこにもインストールされません。もし必要
な方は、/usr/src/PR/doc/patches/にでも、コピーしてご利用くださ
い。」という文言も入れることにする。
<doc> の下の各プロダクトのディレクトリのファイルについて
○README.jp
(リリースノート兼変更履歴)
→ /usr/src/PR/patches/ultra/ にもインストールされる。
(文案)
本パッチは yy/mm/dd 現在、2.0I に施された全てのバグの
修正、および新機能の追加をするものです。なお、これらの
修正時にどのファイルが変更されたかについては、
Changefiles.jp を参照してください。
本パッチをあてることにより、下記の変更がなされます。
98/03/01
* XXXX の機能の xxx というバグを修正。
98/02/14
* yyy をする機能を新規に追加。詳しくは DOC_yyy.jp
を参照してください。
98/01/31
* 新機能 XXXX を追加。詳しくは DOC_XXXX.jp を
参照してください。
(以上)
上記のように、数行でその変更・新機能が記述できない場合
は、別ドキュメントを同じディレクトリに入れる。「累積」
なので、今後のパッチリリース時には、忘れずにこのファイ
ルをインストールする。
○Changefiles.jp
過去の変更ファイル履歴。その日付での変更ファイルは何だっ
たかと、2.0I からの総ファイル変更履歴を両方のせる。
→ /usr/src/PR/patches/ultra/ にもインストールされる。
一般配布のみに添付。
(文案) <- 自動生成されるので、書く必要はない
本パッチ(patchNgyymmdd_ultra)をインストールした際に、
変更されるファイルは下記の通りです。
＜2.0Iからの変更・追加＞
(変更)
/usr/include/PR/os.h
/usr/lib/libultra.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
/usr/lib/libultra_d.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
/usr/lib/libultra_rom.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
(追加)
/usr/sbin/XXXX
/usr/sbin/xxx
/usr/lib/libultra_rom.a 内の yyy.o
＜前のパッチからの変更・追加＞
98/03/01
(変更)
/usr/include/PR/os.h
/usr/sbin/xxx
98/02/14
(変更)
/usr/include/PR/os.h
/usr/lib/libultra.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
/usr/lib/libultra_d.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
/usr/lib/libultra_rom.a 内の xxxxxxx.o
yyyyyyy.o
zzzzzzz.o
(追加)
/usr/lib/libultra_rom.a 内の yyy.o
98/01/31
(変更)
/usr/include/PR/os.h
(追加)
/usr/sbin/XXXX
/usr/sbin/xxx
(以上)
文書作成時ガイドライン
・PC 用は SJIS, 2byte 改行、UNIX 用は EUC, 1byte 改行。
・タブは使わない。
・１行７２文字＋α(漢字の半分はみ出しや、禁則文字)
最悪でも８０文字に収める。
V. リリースの流れ
作成者が動作確認後、パッケージ化して業務、情開、３部の 2nd パー
ティに開発三部として正式リリース(INSTALL.jp も付加)
↓
業務部、(情開も？)にて最終確認
↓
業務部、情開それぞれの判断で、必要に応じて INSTALL.jp を変更
↓
変更した INSTALL.jp を３部に連絡、確認(メールで承認連絡)
↓
業務部はライセンシへ、情開は 2nd パーティへ正式リリース
↓
３部は業務、情開の INSTALL.jp への変更を判断、次回リリースにい
かしていく
VI. その他
現在、ultra, naudio, 64dd の３つがあるが(SGI の場合)、該当外の
リリースはしない。つまり、例えば今回 ultra のパッチをリリース
するとして、過去に 64dd のパッチが累積していたとしても、そのと
きにリリースするのは、patchNgyymmdd_ultra のみとする。
SGI ではライブラリの更新は直接できないため、一旦テンポラリディ
レクトリに .o ファイルをインストールし、その後更新用のシェルス
クリプトを swmgr から自動起動して更新する。その際に使用するテ
ンポラリディレクトリは /tmp/__64ospatches/ とする。(ただし、これ
らの面倒なことは mp が自動的にしてくれる)