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
|
PyPy's Release Process
========================
Release Policy
++++++++++++++
We try to create a stable release a few times a year. These are released on
a branch named like release-pypy3.5-v2.x or release-pypy3.5-v4.x, and each
release is tagged, for instance release-pypy3.5-v4.0.1.
After release, inevitably there are bug fixes. It is the responsibility of
the commiter who fixes a bug to make sure this fix is on the release branch,
so that we can then create a tagged bug-fix release, which will hopefully
happen more often than stable releases.
How to Create a PyPy Release
++++++++++++++++++++++++++++
As a meta rule setting up issues in the tracker for items here may help not
forgetting things. A set of todo files may also work.
Check and prioritize all issues for the release, postpone some if necessary,
create new issues also as necessary. An important thing is to get
the documentation into an up-to-date state!
Release Steps
++++++++++++++
Make the release branch
------------------------
This is needed only in case you are doing a new major version; if not, you can
probably reuse the existing release branch.
We want to be able to freely merge default into the branch and vice-versa;
thus we need to do a complicate dance to avoid to patch the version number
when we do a merge::
$ hg up -r default
$ # edit the version to e.g. 7.0.0-final
$ hg ci
$ hg branch release-pypy2.7-7.x && hg ci
$ hg up -r default
$ # edit the version to 7.1.0-alpha0
$ hg ci
$ hg up -r release-pypy2.7-7.x
$ hg merge default
$ # edit the version to AGAIN 7.0.0-final
$ hg ci
Then, we need to do the same for the 3.x branch::
$ hg up -r py3.5
$ hg merge default # this brings the version fo 7.1.0-alpha0
$ hg branch release-pypy3.5-7.x
$ # edit the version to 7.0.0-final
$ hg ci
$ hg up -r py3.5
$ hg merge release-pypy3.5-7.x
$ # edit the version to 7.1.0-alpha0
$ hg ci
To change the version, you need to edit three files:
- ``module/sys/version.py``
- ``module/cpyext/include/patchlevel.h``
- ``doc/conf.py``
Other steps
-----------
* Make sure the RPython builds on the buildbot pass with no failures
* Maybe bump the SOABI number in module/imp/importing. This has many
implications, so make sure the PyPy community agrees to the change.
* Update and write documentation
* update pypy/doc/contributor.rst (and possibly LICENSE)
pypy/doc/tool/makecontributor.py generates the list of contributors
* rename pypy/doc/whatsnew_head.rst to whatsnew_VERSION.rst
create a fresh whatsnew_head.rst after the release
and add the new file to pypy/doc/index-of-whatsnew.rst
* write release announcement pypy/doc/release-VERSION.rst
The release announcement should contain a direct link to the download page
* Add the new files to pypy/doc/index-of-{whatsnew,release-notes}.rst
* Build and upload the release tar-balls
* go to pypy/tool/release and run
``force-builds.py <release branch>``
The following JIT binaries should be built, however, we need more buildbots
windows, linux-32, linux-64, osx64, armhf-raspberrian, armel,
freebsd64
* wait for builds to complete, make sure there are no failures
* send out a mailing list message asking for people to test before uploading
to prevent having to upload more than once
* add a tag on the pypy/jitviewer repo that corresponds to pypy release, so
that the source tarball can be produced in the next steps
* download the builds, repackage binaries. Tag the release version
and download and repackage source from bitbucket. You may find it
convenient to use the ``repackage.sh`` script in pypy/tool/release to do this.
Otherwise repackage and upload source "-src.tar.bz2" to bitbucket
and to cobra, as some packagers prefer a clearly labeled source package
( download e.g. https://bitbucket.org/pypy/pypy/get/release-2.5.x.tar.bz2,
unpack, rename the top-level directory to "pypy-2.5.0-src", repack, and upload)
* Upload binaries to https://bitbucket.org/pypy/pypy/downloads
* Send out a mailing list message asking for last-minute comments and testing
* RELEASE !
* update pypy.org (under extradoc/pypy.org), rebuild and commit, using the
hashes produced from the ``repackage.sh`` script or by hand
* post announcement on morepypy.blogspot.com
* send announcements to twitter.com, pypy-dev, python-list,
python-announce, python-dev ...
* If all is OK, document the released version
* add a tag on the codespeed web site that corresponds to pypy release
* revise versioning at https://readthedocs.org/projects/pypy
|
