-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRELEASE
184 lines (122 loc) · 6.4 KB
/
RELEASE
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
====================
Making a ZSI Release
====================
The following instructions tell how to go about making a ZSI release.
The Makefile automates many of the more mechanical aspects of the
process.
The documentation is built using the same documentation tools used for
the standard Python documentation. See `Documentation Tools`_ for
information on getting and setting up those tools.
1. Announce your intent to make a release on the mailing list. This
gives folks a day or so to respond with info or last-minute
checkins.
2. Edit setup.cfg to set the version number in the ``[version]``
section, if appropriate. If you change the version number, set
the ``release`` setting in the ``[bdist_rpm]`` section to 1.
3. Make sure CHANGES is up to date, including the version number at
the top.
4. Make sure the documentation is up to date. Try all of the examples,
and make sure they work. For a release candidate, the docs do not
have to be up to date, but we must at least mark the parts of the
docs that are no longer accurate. For a final release, the docs
*must* be up to date with the code.
5. Commit all changes to SVN.
6. Run all the tests; they must all pass. See `Running Tests`_ for
details.
7. Tag the SVN repository. Release tags are of the form::
"ZSI_v" MAJOR "_" MINOR [ "_" PATCHLEVEL ] [ modifier serial ]
where the optional segment containing PATCHLEVEL is included only
if PATCHLEVEL is non-zero. The modifier segment has only been
used for release candidates (so far), for which the modifier is
"RC" and the serial is the number of the candidate for this
particular software version ("1", "2", etc.).
You'll need to tag the ``wstools`` package separately, but using
the same tag.
For example:
% svn mkdir https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI_v2_0_0RC3
% svn copy https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/trunk/zsi \
https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI_v2_0_0RC3/
% svn copy https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/trunk/wstools \
https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI_v2_0_0RC3/
% svn co https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI_v2_0_0RC3
% cd ZSI_v2_0_0RC3/zsi/ZSI
% svn propset "svn:externals" "wstools/ https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI-v2_0_0RC3/wstools" .
% svn commit
8. Export the tagged sources from CVS. You'll need to run the
command::
svn export https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/tags/ZSI_v2_0_0RC3/zsi
9. Build the release from the export. Switch to the export directory
(the one containing setup.py) and run **make kit**.
Create eggs and tarball for supported python versions:
% make kit
10. Rename the PDF documentation. If the patchlevel from setug.cfg is
0, copy doc/zsi.pdf to dist/zsi-$MAJOR.$MINOR.pdf, otherwise copy
it to dist/zsi-$MAJOR.$MINOR.$PATCHLEVEL.pdf. This will leave you
with all the files you need to upload in a single directory
(dist/).
cp doc/zsi.pdf dist/zsi-2.0.pdf
cp doc/guide.pdf dist/guide-zsi-2.0.pdf
11. Using the constructed distribution (usually the .tar.gz version),
build and test the software; they must all pass. See `Running
Tests`_ for details.
12. Use the SourceForge tools to create a release and upload the
files. If appropriate, hide obsolete releases. Hiding old
releases is normally only done if the older release contains
security bugs or other critical bugs that render it unusable.
13. The web pages are in pywebsvcs.sourceforge.net, at the same level
as the zsi directory. Copy zsi.html from zsi/doc into there.
Update index.html to refer (and link) to the new release. Commit
those changes. The cron job will update it every couple of hours.
14. Announce the release:
- Freshmeat. The details of how to do this have been lost to the
travesties of time, but there is a ZSI package there.
- SourceForge.net news: Create a news item in the project
announcing the release.
- Register the release with the Python Package Index (PyPI). This
can be done using **python setup.py register**.
- comp.lang.python.announce
Documentation Tools
-------------------
The Python documentation tools include a script (**mkhowto**) that can
be used on any Unix or Cygwin installation that provides all the
required formatting tools. The recommended way to use them is to
create a symbolic link to **mkhowto** from some directory on your
PATH.
The Python documentation tools can be acquired by any of these three
methods:
- Get a Python source release and unpack it. Create the symlink to
.../Python-VERSION/Doc/tools/mkhowto.
- Get the LaTeX version of the documentation package and unpack it.
Create the symlink to .../Python-Doc-VERSION/tools/mkhowto.
- Get them from SVN. If you have an existing Python checkout, you can
symlink to the .../Doc/tools/mkhowto script in that. If not, then
you only need to check out the Doc/ tree::
svn co http://pywebsvcs.svn.python.org/projects/python/tags/r25/Doc python-Doc
The symlink can then be made to .../someplace/tools/mkhowto.
If you want to skip the symlink, you can specify the MKHOWTO variable
when you run **make kit**::
make MKHOWTO=.../Doc/tools/mkhowto kit
If you're working from unpacked Python sources or a complete Python
checkout, you can just point to that instead of typing the full path
to the **mkhowto** script::
make PYSRCDIR=...
Running Tests
-------------
Before a release, all the tests must run to completion and pass. This
entails running several scripts:
- test/test_zsi.py
- test/test_zsi_net.py
- test/wsdl2py/runTests.py
This is most easily done by setting the PYTHONPATH environment
variable to point to the directory containing the version of the ZSI
package that you want to test.
Before testing, build the software::
python setup.py build
Set PYTHONPATH to point to the built package::
PYTHONPATH=`pwd`/build/lib
The first two scripts can easily be run from any directory; once your
PYTHONPATH is set, just run the scripts::
python test/test_zsi.py
python test/test_zsi_net.py
The third script depends on a configuration file; see the
test/wsdl2py/README file for more information on running these tests.