1756
1797
As well as prioritizing bugs and nominating them against a
1757
1798
target milestone, Launchpad lets core developers offer to mentor others in
1767
To start a new release cycle:
1769
#. Send mail to the list with the key dates, who will be the release
1770
manager, and the main themes or targetted bugs. Ask people to nominate
1771
objectives, or point out an high-risk things that are best done early,
1772
or that interact with other changes.
1774
#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>. There is one
1775
series for every *x.y* release.
1777
Weekly Status Updates
1778
---------------------
1780
TODO: Things to cover:
1782
* Early communication to downstream teams (e.g. Launchpad) about changes in dependencies.
1783
* Reminder re lifecycle and where we're up to right now
1784
* Summary of recent successes and pending work
1785
* Reminder re release objectives
1786
* Reminder re things needing attention, e.g. bug triage, reviews, testing of certain things, etc.
1792
TODO: Get material from http://bazaar-vcs.org/FeatureFreeze.
1796
Making a Release or Release Candidate
1797
-------------------------------------
1799
.. Was previously at http://bazaar-vcs.org/ReleaseChecklist
1801
.. TODO: Still needs more clarity on what's in a RC versus a final
1804
.. TODO: Too much of this is manual but could be automated...
1806
This is the procedure for making a new bzr release:
1808
#. If the release is the first candidate, make a new branch in PQM. (Contact RobertCollins for this step).
1810
Register the branch at https://launchpad.net/products/bzr/+addbranch
1812
#. 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``).
1814
#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``
1816
#. Add the date and release number to ``./NEWS``.
1818
#. Update the release number in the README. (It's not there as of 0.15, but please check).
1820
#. Commit these changes to the release branch, using a command like::
1822
bzr commit -m "(jam) Release 0.12rc1."
1824
The diff before you commit will be something like::
1826
=== modified file 'NEWS'
1827
--- NEWS 2006-10-23 13:11:17 +0000
1828
+++ NEWS 2006-10-23 22:50:50 +0000
1831
+bzr 0.12rc1 2006-10-23
1836
=== modified file 'bzrlib/__init__.py'
1837
--- bzrlib/__init__.py 2006-10-16 01:47:43 +0000
1838
+++ bzrlib/__init__.py 2006-10-23 22:49:46 +0000
1840
# Python version 2.0 is (2, 0, 0, 'final', 0)." Additionally we use a
1841
# releaselevel of 'dev' for unreleased under-development code.
1843
-version_info = (0, 12, 0, 'dev', 0)
1844
+version_info = (0, 12, 0, 'candidate', 1)
1846
if version_info[3] == 'final':
1847
version_string = '%d.%d.%d' % version_info[:3]
1849
#. Submit those changes to PQM for merge into the appropriate release
1852
#. When PQM succeeds, pull down the master release branch.
1854
#. Run ``make dist`` from a clean copy of the release branch; this will
1855
produce a tarball and prompt you to sign it.
1857
#. Unpack the tarball into a temporary directory and run ``make check`` in
1860
#. 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. ::
1862
python setup.py install --root=installed
1863
PYTHONPATH=installed/usr/lib/python2.4/site-packages installed/usr/bin/bzr
1866
Publishing the release
1867
----------------------
1869
Now you have the releasable product. The next step is making it
1870
available to the world.
1872
#. In <https://launchpad.net/bzr/> click the "Release series" for this
1873
series, to take you to e.g. <https://launchpad.net/bzr/1.1>. Then
1874
click "Register a release", and add information about this release.
1876
#. Within that release, upload the source tarball and the GPG signature.
1878
(These used to also be uploaded to
1879
<sftp://escudero.ubuntu.com/srv/bazaar.canonical.com/www/releases/src>
1880
but that's not accessible to all developers, and gets some mime types
1881
wrong... This upload can still be done with ``make
1882
dist-upload-escudero``.)
1884
#. Link from http://bazaar-vcs.org/Download to the tarball and signature.
1886
#. Update http://doc.bazaar-vcs.org/ to have a directory of documentation
1887
for this release. (Controlled by the ``update-bzr-docs`` script on
1888
escudero, and also update the ``latest`` symlink in
1889
``/srv/bazaar.canonical.com/doc/``.)
1891
#. Announce on the `Bazaar home page`__
1893
__ http://bazaar-vcs.org/
1896
Announcing the release
1897
----------------------
1899
Now that the release is publicly available, tell people about it.
1901
#. Announce to ``bazaar-announce`` and ``bazaar`` mailing lists.
1902
The announce mail will look something like this:
1904
| Subject: bzr 0.11 release candidate 1
1906
| 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).
1909
| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz
1910
| and GPG signature:
1911
| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz.sig
1913
| DESCRIBE-CHANGES-IN-OVERVIEW-HERE
1915
| DESCRIBE-when the next release will be (if there is another - i.e. this is a release candidate)
1917
| Many thanks to all the contributors to this release! I've included the
1918
| contents of NEWS for VERSION below:
1920
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.
1922
(RC announcements should remind plugin maintainers to update their plugins.)
1924
* 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.
1926
* 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.
1928
#. Update the `news side menu`__ -- this currently requires downloading the file, editing it, deleting it, and uploading a replacement.
1930
__ http://bazaar-vcs.org/site/menu?action=AttachFile&do=view&target=news.html
1932
#. 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.
1934
#. Announce on http://freshmeat.net/projects/bzr/
1936
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.
1938
#. Update http://en.wikipedia.org/wiki/Bzr -- this should be done for final releases but not Release Candidates.
1940
#. Package maintainers should update packages when they see the
1945
#. Post to http://mail.python.org/mailman/listinfo/python-announce-list for major releases
1947
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
1950
python setup.py register
1952
Remember to check the results afterwards.
1955
Merging the released code back to trunk
1956
---------------------------------------
1958
Merge the release branch back into the trunk. Check that changes in NEWS
1959
were merged into the right sections. If it's not already done, advance
1960
the version number in ``bzr`` and ``bzrlib/__init__.py``. Submit this
1961
back into pqm for bzr.dev.
1965
Making Win32 installers
1966
-----------------------
1968
**XXX:** This information is now probably obsolete, as Alexander uploads
1969
direct to Launchpad. --mbp 20080116
1971
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.
1973
#. 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.
1975
#. Upload to the Launchpad page for this release.
1977
#. Upload to escudero (to the b.c.c/www/releases/win32 directory) using sftp, lftp or rsync
1979
#. Cat the contents of the .sha1 files into the SHA1SUM.
1981
#. 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 (>).
1983
#. Verify once again that everything is correct with ``sha1sum -c SHA1SUM`` and ``md5sum -c MD5SUM``.
1985
#. 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).
1987
#. Make sure these urls work as expected:
1989
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe
1991
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe.asc
1993
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe
1995
http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe.asc
1997
http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe
1999
http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe.asc
2001
They should all try to download a file with the correct version number.
2003
#. Update http://bazaar-vcs.org/Download to indicate the newly available versions.
2005
#. Update http://bazaar-vcs.org/WindowsDownloads to have the correct version number as well as the correct sha1sum displayed.
2008
The Bazaar PPA archive
2009
----------------------
2011
We build Ubuntu ``.deb`` packages for Bazaar as an important part of the release
2012
process. These packages are hosted in a `Personal Package Archive (PPA)`__ on
2013
Launchpad, at <https://launchpad.net/~bzr/+archive>.
2015
__ https://help.launchpad.net/PPAQuickStart
2017
We build packages for every supported Ubuntu release
2018
<https://wiki.ubuntu.com/Releases>. Packages need no longer be updated
2019
when the release passes end-of-life because all users should have then
2022
The ``debian/`` directory containing the packaging information is kept in
2023
branches on Launchpad, named like
2024
<https://code.launchpad.net/~bzr/bzrtools/packaging-dapper>
2026
Updating the PPA for a new release
2027
----------------------------------
2029
Preconditions for building these packages:
2031
* You must have a Launchpad account and be a member of the `~bzr`__ team
2033
__ https://edge.launchpad.net/~bzr/+members>
2035
* You must have a GPG key registered to your Launchpad account.
2037
* Configure ``dput`` to upload to our PPA with this section in your
2041
fqdn = ppa.launchpad.net
2043
incoming = ~bzr/ubuntu
2045
allow_unsigned_uploads = 0
2047
* You need a Ubuntu (or probably Debian) machine, and ::
2049
sudo apt-get install build-essential devscripts dput
2051
Here is the process; there are some steps which should be automated in
2054
#. You will need a working directory for each supported release, such as
2055
``~/bzr/Packaging/dapper``
2057
#. Download the official tarball of the release to e.g. ``~/bzr/Releases``
2059
#. Copy the original tarball into your per-disto directory, then untar it
2060
and if necessary rename it::
2062
cp -l ~/bzr/Releases/bzrtools-1.3.0.tar.gz bzrtools_1.3.0.orig.tar.gz
2063
tar xfvz bzrtools_1.3.0.orig.tar.gz
2064
mv bzrtools bzrtools-1.3.0
2066
#. Change into that directory and check out the packaging branch::
2070
bzr+ssh://bazaar.launchpad.net/~bzr/bzrtools/packaging-dapper \
2073
#. For Bazaar plugins, change the ``debian/control`` file to express a
2074
dependency on the correct version of ``bzr``.
2076
For bzrtools this is typically::
2078
Build-Depends-Indep: bzr (>= 1.3~), rsync
2079
Depends: ${python:Depends}, bzr (>= 1.3~), bzr (<< 1.4~), patch
2081
#. Make a new ``debian/changelog`` entry for the new release,
2082
either by using ``dch`` or just editing the file::
2084
dch -v '1.3.0-1~bazaar1~dapper1' -D dapper
2086
dch will default to the distro you're working in and this isn't checked
2087
against the version number (which is just our conversion). So make
2090
Make sure you have the correct email address for yourself, version
2091
number, and distribution. It should look something like this::
2093
> bzrtools (1.3.0-1~bazaar1~dapper1) dapper; urgency=low
2095
> * New upstream release.
2097
> -- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
2099
If you need to upload the package again to fix a problem, normally you
2100
should increment the last number in the version number, following the
2101
distro name. Make sure not to omit the initial ``-1``, and make sure
2102
that the distro name in the version is consistent with the target name
2103
outside the parenthesis.
2105
#. Commit these changes into the packaging branch::
2107
bzr ci -m '1.3.0-1~bazaar1~dapper1: New upstream release.' debian
2109
#. Build a source package::
2113
This will create a ``.changes`` file in the per-distro directory,
2114
and should invoke gpg to sign it with your key.
2115
Check that file is reasonable: it should be uploading to the intended
2116
distribution, have a .orig file included, and the right version number.
2118
#. Upload into the PPA::
2120
dput bzr-ppa ../bzrtools__1.3.0-1\~bazaar1\~dapper1_source.changes
2122
Don't forget the ``bzr-ppa`` component or dput will try to upload into
2123
the main archive by default. You can disable this by adding this
2124
section to your ``.dput.cf``::
2127
fqdn = SPECIFY.A.PPA.NAME
2129
#. You should soon get an "upload accepted" mail from Launchpad, which
2130
means that your package is waiting to be built. You can then track its
2131
progress in <https://launchpad.net/~bzr/+archive> and
2132
<https://launchpad.net/~bzr/+archive/+builds>.
added
removed
doc/developers/HACKING.txt
