1786
1797
As well as prioritizing bugs and nominating them against a
1787
1798
target milestone, Launchpad lets core developers offer to mentor others in
1797
To start a new release cycle:
1799
#. Send mail to the list with the key dates, who will be the release
1800
manager, and the main themes or targetted bugs. Ask people to nominate
1801
objectives, or point out an high-risk things that are best done early,
1802
or that interact with other changes.
1804
#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>. There is one
1805
series for every *x.y* release.
1807
Weekly Status Updates
1808
---------------------
1810
TODO: Things to cover:
1812
* Early communication to downstream teams (e.g. Launchpad) about changes in dependencies.
1813
* Reminder re lifecycle and where we're up to right now
1814
* Summary of recent successes and pending work
1815
* Reminder re release objectives
1816
* Reminder re things needing attention, e.g. bug triage, reviews, testing of certain things, etc.
1822
TODO: Get material from http://bazaar-vcs.org/FeatureFreeze.
1826
Making a Release or Release Candidate
1827
-------------------------------------
1829
.. Was previously at http://bazaar-vcs.org/ReleaseChecklist
1831
.. TODO: Still needs more clarity on what's in a RC versus a final
1834
.. TODO: Too much of this is manual but could be automated...
1836
This is the procedure for making a new bzr release:
1838
#. If the release is the first candidate, make a new branch in PQM. (Contact RobertCollins for this step).
1840
Register the branch at https://launchpad.net/products/bzr/+addbranch
1842
#. Run the automatic test suite and any non-automated tests. (For example, try a download over http; these should eventually be scripted though not automatically run.). Try to have all optional dependencies installed so that there are no tests skipped. Also make sure that you have the c extensions compiled (``make`` or ``python setup.py build_ext -i``).
1844
#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``
1846
#. Add the date and release number to ``./NEWS``.
1848
#. Update the release number in the README. (It's not there as of 0.15, but please check).
1850
#. Commit these changes to the release branch, using a command like::
1852
bzr commit -m "(jam) Release 0.12rc1."
1854
The diff before you commit will be something like::
1856
=== modified file 'NEWS'
1857
--- NEWS 2006-10-23 13:11:17 +0000
1858
+++ NEWS 2006-10-23 22:50:50 +0000
1861
+bzr 0.12rc1 2006-10-23
1866
=== modified file 'bzrlib/__init__.py'
1867
--- bzrlib/__init__.py 2006-10-16 01:47:43 +0000
1868
+++ bzrlib/__init__.py 2006-10-23 22:49:46 +0000
1870
# Python version 2.0 is (2, 0, 0, 'final', 0)." Additionally we use a
1871
# releaselevel of 'dev' for unreleased under-development code.
1873
-version_info = (0, 12, 0, 'dev', 0)
1874
+version_info = (0, 12, 0, 'candidate', 1)
1876
if version_info[3] == 'final':
1877
version_string = '%d.%d.%d' % version_info[:3]
1879
#. Send the changes to PQM, to update the official master branch.
1881
#. When PQM succeeds, pull down the master release branch.
1883
#. Merge the release branch back into the trunk. Check that changes in NEWS were merged into the right sections. If it's not already done, advance the version number in bzr and bzrlib/__init__.py Submit this back into pqm for bzr.dev.
1885
#. Make a distribution directory by running e.g. ``bzr export /tmp/bzr-<version>/`` in the working directory.
1887
#. Run make in /tmp/bzr-<version>. This creates the extensions from the pyrex source.
1889
#. Run the test suite in the distribution directory
1891
#. Run ``setup.py install`` --root=prefix to do a test install into your system directory, home directory, or some other prefix. Check the install worked and that the installed version is usable. (run the bzr script from the installed path with PYTHONPATH set to the site-packages directory it created). i.e. ::
1893
python setup.py install --root=installed
1894
PYTHONPATH=installed/usr/lib/python2.4/site-packages installed/usr/bin/bzr
1896
#. Clean the tree to get rid of .pyc files etc: make clean && rm -rf build && rm bzrlib/_*.c bzrlib/_*.so
1898
#. Generate the reference documentation in text format: make doc/en/user-reference/bzr_man.txt.
1900
#. Change back to your original branch and then run: make clean && make to create the compiled pyrex extensions. You then need to copy the .c files over to the exported directory.
1902
``find . -name "*.c"`` will tell you which files you need.
1904
#. Create the release tarball::
1906
cd /tmp && tar czf bzr-<version>.tar.gz bzr-<version>
1908
#. Sign the tarball with e.g. ``gpg --detach-sign -a bzr-0.10rc1.tar.gz``
1911
Publishing the release
1912
----------------------
1914
Now you have the releasable product. The next step is making it
1915
available to the world.
1917
#. In <https://launchpad.net/bzr/> click the "Release series" for this
1918
series, to take you to e.g. <https://launchpad.net/bzr/1.1>. Then
1919
click "Register a release", and add information about this release.
1921
#. Within that release, upload the source tarball and the GPG signature.
1923
(These used to also be uploaded to
1924
<sftp://escudero.ubuntu.com/srv/bazaar.canonical.com/www/releases/src>
1925
but that's not accessible to all developers, and gets some mime types
1928
#. Link from http://bazaar-vcs.org/Download to the tarball and signature.
1930
#. Update http://doc.bazaar-vcs.org/ to have a directory of documentation
1931
for this release. (Controlled by the ``update-bzr-docs`` script on
1932
escudero, and also update the ``latest`` symlink in
1933
``/srv/bazaar.canonical.com/doc/``.)
1935
#. Announce on the `Bazaar home page`__
1937
__ http://bazaar-vcs.org/
1940
Announcing the release
1941
----------------------
1943
Now that the release is publicly available, tell people about it.
1945
#. Announce to ``bazaar-announce`` and ``bazaar`` mailing lists.
1946
The announce mail will look something like this:
1948
| Subject: bzr 0.11 release candidate 1
1950
| INTRO HERE. Mention the release number and date, and why the release. (i.e. release candidate for testing, final release of a version, backport/bugfix etc).
1953
| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz
1954
| and GPG signature:
1955
| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz.sig
1957
| DESCRIBE-CHANGES-IN-OVERVIEW-HERE
1959
| DESCRIBE-when the next release will be (if there is another - i.e. this is a release candidate)
1961
| Many thanks to all the contributors to this release! I've included the
1962
| contents of NEWS for VERSION below:
1964
To generate the data from NEWS, just copy and paste the relevant news section and clean it up as appropriate. The main clean-up task is to confirm that all major changes are indeed covered. This can be done by running ``bzr log`` back to the point when the branch was opened and cross checking the changes against the NEWS entries.
1966
(RC announcements should remind plugin maintainers to update their plugins.)
1968
* For point releases (i.e. a release candidate, or an incremental fix to a released version) take everything in the relevant NEWS secion : for 0.11rc2 take everything in NEWS from the bzr 0.11rc2 line to the bzr 0.11rc1 line further down.
1970
* For major releases (i.e. 0.11, 0.12 etc), take all the combined NEWS sections from within that version: for 0.11 take all of the 0.11 specific section, plus 0.11rc2, plus 0.11rc1 etc.
1972
#. Update the `news side menu`__ -- this currently requires downloading the file, editing it, deleting it, and uploading a replacement.
1974
__ http://bazaar-vcs.org/site/menu?action=AttachFile&do=view&target=news.html
1976
#. Update the IRC channel topic. Use the ``/topic`` command to do this, ensuring the new topic text keeps the project name, web site link, etc.
1978
#. Announce on http://freshmeat.net/projects/bzr/
1980
This should be done for both release candidates and final releases. If you do not have a Freshmeat account yet, ask one of the existing admins.
1982
#. Update http://en.wikipedia.org/wiki/Bzr -- this should be done for final releases but not Release Candidates.
1984
#. Package maintainers should update packages when they see the
1989
#. Post to http://mail.python.org/mailman/listinfo/python-announce-list for major releases
1991
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
1994
python setup.py register
1996
Remember to check the results afterwards.
1999
Making Win32 installers
2000
-----------------------
2002
**XXX:** This information is now probably obsolete, as Alexander uploads
2003
direct to Launchpad. --mbp 20080116
2005
Alexander Belchenko has been very good about getting packaged installers compiled (see Win32ReleaseChecklist for details). He generally e-mails John Arbash Meinel when they are ready. This is just a brief checklist of what needs to be done.
2007
#. Download and verify the sha1 sums and gpg signatures. Frequently the sha1 files are in dos mode, and need to be converted to unix mode (strip off the trailing ``\r``) before they veryify correctly.
2009
#. Upload to the Launchpad page for this release.
2011
#. Upload to escudero (to the b.c.c/www/releases/win32 directory) using sftp, lftp or rsync
2013
#. Cat the contents of the .sha1 files into the SHA1SUM.
2015
#. Update the SHA1SUM and MD5SUM files using something like ``md5sum bzr-0.14.0.win32.exe >> MD5SUM``. Make sure you use append (>>) rather than overwrite (>).
2017
#. Verify once again that everything is correct with ``sha1sum -c SHA1SUM`` and ``md5sum -c MD5SUM``.
2019
#. Update ``.htaccess`` so that the 'bzr-latest.win32.exe' links point to the latest release. This is not done for candidate releases, only for final releases. (example: bzr-0.14.0, but not bzr-0.14.0rc1).
2021
#. Make sure these urls work as expected:
2023
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe
2025
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe.asc
2027
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe
2029
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe.asc
2031
http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe
2033
http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe.asc
2035
They should all try to download a file with the correct version number.
2037
#. Update http://bazaar-vcs.org/Download to indicate the newly available versions.
2039
#. Update http://bazaar-vcs.org/WindowsDownloads to have the correct version number as well as the correct sha1sum displayed.
2042
The Bazaar PPA archive
2043
----------------------
2045
We build Ubuntu ``.deb`` packages for Bazaar as an important part of the release
2046
process. These packages are hosted in a `Personal Package Archive (PPA)`__ on
2047
Launchpad, at <https://launchpad.net/~bzr/+archive>.
2049
__ https://help.launchpad.net/PPAQuickStart
2051
We build packages for every supported Ubuntu release
2052
<https://wiki.ubuntu.com/Releases>. Packages need no longer be updated
2053
when the release passes end-of-life because all users should have then
2056
The ``debian/`` directory containing the packaging information is kept in
2057
branches on Launchpad, named like
2058
<https://code.launchpad.net/~bzr/bzrtools/packaging-dapper>
2060
Updating the PPA for a new release
2061
----------------------------------
2063
Preconditions for building these packages:
2065
* You must have a Launchpad account and be a member of the `~bzr`__ team
2067
__ https://edge.launchpad.net/~bzr/+members>
2069
* You must have a GPG key registered to your Launchpad account.
2071
* Configure ``dput`` to upload to our PPA with this section in your
2075
fqdn = ppa.launchpad.net
2077
incoming = ~bzr/ubuntu
2079
allow_unsigned_uploads = 0
2081
* You need a Ubuntu (or probably Debian) machine, and ::
2083
sudo apt-get install build-essential devscripts dput
2085
Here is the process; there are some steps which should be automated in
2088
#. You will need a working directory for each supported release, such as
2089
``~/bzr/Packaging/dapper``
2091
#. Download the official tarball of the release to e.g. ``~/bzr/Releases``
2093
#. Copy the original tarball into your per-disto directory, then untar it
2094
and if necessary rename it::
2096
cp -l ~/bzr/Releases/bzrtools-1.3.0.tar.gz bzrtools_1.3.0.orig.tar.gz
2097
tar xfvz bzrtools_1.3.0.orig.tar.gz
2098
mv bzrtools bzrtools-1.3.0
2100
#. Change into that directory and check out the packaging branch::
2104
bzr+ssh://bazaar.launchpad.net/~bzr/bzrtools/packaging-dapper \
2107
#. For Bazaar plugins, change the ``debian/control`` file to express a
2108
dependency on the correct version of ``bzr``.
2110
For bzrtools this is typically::
2112
Build-Depends-Indep: bzr (>= 1.3~), rsync
2113
Depends: ${python:Depends}, bzr (>= 1.3~), bzr (<< 1.4~), patch
2115
#. Make a new ``debian/changelog`` entry for the new release,
2116
either by using ``dch`` or just editing the file::
2118
dch -v '1.3.0-1~bazaar1~dapper1' -D dapper
2120
dch will default to the distro you're working in and this isn't checked
2121
against the version number (which is just our conversion). So make
2124
Make sure you have the correct email address for yourself, version
2125
number, and distribution. It should look something like this::
2127
> bzrtools (1.3.0-1~bazaar1~dapper1) dapper; urgency=low
2129
> * New upstream release.
2131
> -- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
2133
If you need to upload the package again to fix a problem, normally you
2134
should increment the last number in the version number, following the
2135
distro name. Make sure not to omit the initial ``-1``, and make sure
2136
that the distro name in the version is consistent with the target name
2137
outside the parenthesis.
2139
#. Commit these changes into the packaging branch::
2141
bzr ci -m '1.3.0-1~bazaar1~dapper1: New upstream release.' debian
2143
#. Build a source package::
2147
This will create a ``.changes`` file in the per-distro directory,
2148
and should invoke gpg to sign it with your key.
2149
Check that file is reasonable: it should be uploading to the intended
2150
distribution, have a .orig file included, and the right version number.
2152
#. Upload into the PPA::
2154
dput bzr-ppa ../bzrtools__1.3.0-1\~bazaar1\~dapper1_source.changes
2156
Don't forget the ``bzr-ppa`` component or dput will try to upload into
2157
the main archive by default. You can disable this by adding this
2158
section to your ``.dput.cf``::
2161
fqdn = SPECIFY.A.PPA.NAME
2163
#. You should soon get an "upload accepted" mail from Launchpad, which
2164
means that your package is waiting to be built. You can then track its
2165
progress in <https://launchpad.net/~bzr/+archive> and
2166
<https://launchpad.net/~bzr/+archive/+builds>.
added
removed
doc/developers/HACKING.txt
