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
|
Release management of SigScheme
===============================
Acknowledgement
---------------
A part of this document is based on
http://lists.freedesktop.org/archives/uim/2005-November/001381.html[Release
Manual for uim (draft)] contributed to http://code.google.com/p/uim/[uim
project] by Jeroen Ruigrok van der Werven. Thank you for cooperation.
Versioning scheme
-----------------
A SigScheme version number is built up as follows:
----------------------------------------------------------------
major.minor.patchlevel
----------------------------------------------------------------
The 'minor' number is incremented for every stable release. As an example:
1.2.3 will become 1.3.0 upon a new release.
There's no limit to the 'minor' version's number, it will continue past 9 with
10, in other words: after release 1.9.2 we will see release 1.10.0.
The 'patchlevel' number will only be increased in the case of a bug fix or a
security fix.
There is no separate versioning for unstable versions, this is simply the
source control's trunk revision with development snapshots being called
`sigscheme-snapshot-YYYYMMDD`. With `YYYYMMDD` standing for the year in four,
the month in two, and the day in two digits when the snapshot was taken.
And no 'alpha', 'beta' or 'RC' versions are released for now since the source
codes are still drastically changing and no profit can be obtained from a
feature freeze.
Release procedures
------------------
Documents update
~~~~~~~~~~~~~~~~
Update `RELNOTE` and `NEWS`.
Declaration
~~~~~~~~~~~
Let all SigScheme developers know that a release is emerging, and make sure
that no developer is having a problem on the release.
Versioning
~~~~~~~~~~
Confirm the version number written in `AC_INIT()` of the `configure.in` and
SSCM_VERSION_* of sigscheme.h prior to a release.
And do not forget updating `src/libtool-version.mk` if `libsscm` ABI has been
altered from previous version.
Finally, update LIBGCROOTS_URL in `make-dist.sh`.
Test
~~~~
Make all tests passed.
----------------------------------------------------------------
$ ./configure --enable-maintainer-mode --enable-conf=full
$ make check
----------------------------------------------------------------
Tagging
~~~~~~~
A release must be branched and tagged for development management.
----------------------------------------------------------------
$ git branch sigscheme-x.y <start-point>
$ git push origin sigscheme-x.y
$ git tag -a sigscheme-x.y.z <commit on sigscheme-x.y>
$ git push --tags
----------------------------------------------------------------
If the release is a snapshot, tag as follows:
----------------------------------------------------------------
$ git tag -a sigscheme-snapshot-YYYYMMDD
$ git push --tags
----------------------------------------------------------------
Packaging
~~~~~~~~~
----------------------------------------------------------------
$ cd /tmp
$ git clone https://code.google.com/p/uim.sigscheme/
$ git checkout sigscheme-x.y.z
$ ./make-dist.sh
----------------------------------------------------------------
It produces:
----------------------------------------------------------------
sigscheme-x.y.z.tar.gz
sigscheme-x.y.z.tar.bz2
sigscheme-x.y.z.sum
----------------------------------------------------------------
Publishing and announcements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upload the file by the official uploading script:
http://code.google.com/p/support/wiki/ScriptedUploads
Don't forget adding appropriate tags as follows.
Final release:
----------------------------------------------------------------
googlecode-upload.py -u yamakenz -p sigscheme \
-s 'SigScheme 0.8.0' -l 'Stable,Featured' \
sigscheme-0.8.0.tar.bz2
----------------------------------------------------------------
Alpha or beta release:
----------------------------------------------------------------
googlecode-upload.py -u yamakenz -p sigscheme \
-s 'SigScheme 0.8.0-alpha' -l 'Unstable' \
sigscheme-0.8.0-alpha.tar.bz2
----------------------------------------------------------------
Snapshot release:
----------------------------------------------------------------
googlecode-upload.py -u yamakenz -p sigscheme \
-s 'SigScheme trunk-snapshot20070703' -l 'Snapshot' \
sigscheme-trunk-snapshot20070703.tar.bz2
----------------------------------------------------------------
And untag 'Featured' from previous final release files by the web
interface.
Then update the web pages.
http://code.google.com/p/sigscheme/
http://code.google.com/p/sigscheme/wiki/SigScheme
http://code.google.com/p/sigscheme/wiki/Download
Update 'SigScheme' page first and copy it into the project description
(homepage).
<obsolete>
The checksums of the files must not directly be written into the
anyone-rewritable wikipage, to prevent spoofings. It should be a link to the
release announce which contain the checksum information.
</obsolete>
And send a message to {sigscheme-ja,uim-en,uim-ja}@googlegroups.com
----------------------------------------------------------------
<write announcement here>
http://code.google.com/p/sigscheme/wiki/Download
MD5 (sigscheme-0.8.0-example.tar.gz) = cff14a6ad95a6a1303b527a86d27bff4
MD5 (sigscheme-0.8.0-example.tar.bz2) = b2e96af101a0c51df697990f6311f6f2
SHA1 (sigscheme-0.8.0-example.tar.gz) = 3f152c4aa77a3a44d9f74800a8b9d8d3b6c16771
SHA1 (sigscheme-0.8.0-example.tar.bz2) = c870c3e8585ce8e4200fe3247021802d922781c6
<append RELNOTE here>
----------------------------------------------------------------
Update Freshmeat entry at last.
http://freshmeat.net/projects/sigscheme/
|
