~bzr-pqm/bzr/bzr.dev : revision 3383.2.3

1758

fixing them. Nice.

1759

1760

1761

Managing a Release

1762

==================

1763

1764

Starting a Release

1765

------------------

1766

1767

To start a new release cycle:

1768

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.

1773

1774

#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>. There is one

1775

series for every *x.y* release.

1776

1777

Weekly Status Updates

1778

---------------------

1779

1780

TODO: Things to cover:

1781

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.

1787

1788

1789

Feature Freeze

1790

--------------

1791

1792

TODO: Get material from http://bazaar-vcs.org/FeatureFreeze.

1793

1794

1795

1796

Making a Release or Release Candidate

1797

-------------------------------------

1798

1799

.. Was previously at http://bazaar-vcs.org/ReleaseChecklist

1800

1801

.. TODO: Still needs more clarity on what's in a RC versus a final

1802

.. release?

1803

1804

.. TODO: Too much of this is manual but could be automated...

1805

1806

This is the procedure for making a new bzr release:

1807

1808

#. If the release is the first candidate, make a new branch in PQM. (Contact RobertCollins for this step).

1809

1810

Register the branch at https://launchpad.net/products/bzr/+addbranch

1811

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``).

1813

1814

#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``

1815

1816

#. Add the date and release number to ``./NEWS``.

1817

1818

#. Update the release number in the README. (It's not there as of 0.15, but please check).

1819

1820

#. Commit these changes to the release branch, using a command like::

1821

1822

bzr commit -m "(jam) Release 0.12rc1."

1823

1824

The diff before you commit will be something like::

1825

1826

=== modified file 'NEWS'

1827

--- NEWS 2006-10-23 13:11:17 +0000

1828

+++ NEWS 2006-10-23 22:50:50 +0000

1829

@@ -1,4 +1,4 @@

1830

-IN DEVELOPMENT

1831

+bzr 0.12rc1 2006-10-23

1832

1833

IMPROVEMENTS:

1834

1835

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

1839

@@ -35,7 +35,7 @@

1840

# Python version 2.0 is (2, 0, 0, 'final', 0)." Additionally we use a

1841

# releaselevel of 'dev' for unreleased under-development code.

1842

1843

-version_info = (0, 12, 0, 'dev', 0)

1844

+version_info = (0, 12, 0, 'candidate', 1)

1845

1846

if version_info[3] == 'final':

1847

version_string = '%d.%d.%d' % version_info[:3]

1848

1849

#. Send the changes to PQM, to update the official master branch.

1850

1851

#. When PQM succeeds, pull down the master release branch.

1852

1853

#. 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.

1854

1855

#. Make a distribution directory by running e.g. ``bzr export /tmp/bzr-<version>/`` in the working directory.

1856

1857

#. Run make in /tmp/bzr-<version>. This creates the extensions from the pyrex source.

1858

1859

#. Run the test suite in the distribution directory

1860

1861

#. 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

1863

python setup.py install --root=installed

1864

PYTHONPATH=installed/usr/lib/python2.4/site-packages installed/usr/bin/bzr

1865

1866

#. Clean the tree to get rid of .pyc files etc: make clean && rm -rf build && rm bzrlib/_*.c bzrlib/_*.so

1867

1868

#. Generate the reference documentation in text format: make doc/en/user-reference/bzr_man.txt.

1869

1870

#. 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.

1871

1872

``find . -name "*.c"`` will tell you which files you need.

1873

1874

#. Create the release tarball::

1875

1876

cd /tmp && tar czf bzr-<version>.tar.gz bzr-<version>

1877

1878

#. Sign the tarball with e.g. ``gpg --detach-sign -a bzr-0.10rc1.tar.gz``

1879

1880

1881

Publishing the release

1882

----------------------

1883

1884

Now you have the releasable product. The next step is making it

1885

available to the world.

1886

1887

#. In <https://launchpad.net/bzr/> click the "Release series" for this

1888

series, to take you to e.g. <https://launchpad.net/bzr/1.1>. Then

1889

click "Register a release", and add information about this release.

1890

1891

#. Within that release, upload the source tarball and the GPG signature.

1892

1893

(These used to also be uploaded to

1894

<sftp://escudero.ubuntu.com/srv/bazaar.canonical.com/www/releases/src>

1895

but that's not accessible to all developers, and gets some mime types

1896

wrong...)

1897

1898

#. Link from http://bazaar-vcs.org/Download to the tarball and signature.

1899

1900

#. Update http://doc.bazaar-vcs.org/ to have a directory of documentation

1901

for this release. (Controlled by the ``update-bzr-docs`` script on

1902

escudero, and also update the ``latest`` symlink in

1903

``/srv/bazaar.canonical.com/doc/``.)

1904

1905

#. Announce on the `Bazaar home page`__

1906

1907

__ http://bazaar-vcs.org/

1908

1909

1910

Announcing the release

1911

----------------------

1912

1913

Now that the release is publicly available, tell people about it.

1914

1915

#. Announce to ``bazaar-announce`` and ``bazaar`` mailing lists.

1916

The announce mail will look something like this:

1917

1918

| Subject: bzr 0.11 release candidate 1

1919

|

1920

| 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).

1921

|

1922

| Tarballs:

1923

| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz

1924

| and GPG signature:

1925

| http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz.sig

1926

|

1927

| DESCRIBE-CHANGES-IN-OVERVIEW-HERE

1928

|

1929

| DESCRIBE-when the next release will be (if there is another - i.e. this is a release candidate)

1930

|

1931

| Many thanks to all the contributors to this release! I've included the

1932

| contents of NEWS for VERSION below:

1933

1934

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.

1935

1936

(RC announcements should remind plugin maintainers to update their plugins.)

1937

1938

* 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.

1939

1940

* 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.

1941

1942

#. Update the `news side menu`__ -- this currently requires downloading the file, editing it, deleting it, and uploading a replacement.

1943

1944

__ http://bazaar-vcs.org/site/menu?action=AttachFile&do=view&target=news.html

1945

1946

#. 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.

1947

1948

#. Announce on http://freshmeat.net/projects/bzr/

1949

1950

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.

1951

1952

#. Update http://en.wikipedia.org/wiki/Bzr -- this should be done for final releases but not Release Candidates.

1953

1954

#. Package maintainers should update packages when they see the

1955

announcement.

1956

1957

#. Blog about it.

1958

1959

#. Post to http://mail.python.org/mailman/listinfo/python-announce-list for major releases

1960

1961

#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best

1962

done by running ::

1963

1964

python setup.py register

1965

1966

Remember to check the results afterwards.

1967

1968

1969

Making Win32 installers

1970

-----------------------

1971

1972

**XXX:** This information is now probably obsolete, as Alexander uploads

1973

direct to Launchpad. --mbp 20080116

1974

1975

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.

1976

1977

#. 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.

1978

1979

#. Upload to the Launchpad page for this release.

1980

1981

#. Upload to escudero (to the b.c.c/www/releases/win32 directory) using sftp, lftp or rsync

1982

1983

#. Cat the contents of the .sha1 files into the SHA1SUM.

1984

1985

#. 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 (>).

1986

1987

#. Verify once again that everything is correct with ``sha1sum -c SHA1SUM`` and ``md5sum -c MD5SUM``.

1988

1989

#. 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).

1990

1991

#. Make sure these urls work as expected:

1992

1993

http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe

1994

1995

http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe.asc

1996

1997

http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe

1998

1999

http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe.asc

2000

2001

http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe

2002

2003

http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe.asc

2004

2005

They should all try to download a file with the correct version number.

2006

2007

#. Update http://bazaar-vcs.org/Download to indicate the newly available versions.

2008

2009

#. Update http://bazaar-vcs.org/WindowsDownloads to have the correct version number as well as the correct sha1sum displayed.

2010

2011

2012

The Bazaar PPA archive

2013

----------------------

2014

2015

We build Ubuntu ``.deb`` packages for Bazaar as an important part of the release

2016

process. These packages are hosted in a `Personal Package Archive (PPA)`__ on

2017

Launchpad, at <https://launchpad.net/~bzr/+archive>.

2018

2019

__ https://help.launchpad.net/PPAQuickStart

2020

2021

We build packages for every supported Ubuntu release

2022

<https://wiki.ubuntu.com/Releases>. Packages need no longer be updated

2023

when the release passes end-of-life because all users should have then

2024

update.

2025

2026

The ``debian/`` directory containing the packaging information is kept in

2027

branches on Launchpad, named like

2028

<https://code.launchpad.net/~bzr/bzrtools/packaging-dapper>

2029

2030

Updating the PPA for a new release

2031

----------------------------------

2032

2033

Preconditions for building these packages:

2034

2035

* You must have a Launchpad account and be a member of the `~bzr`__ team

2036

2037

__ https://edge.launchpad.net/~bzr/+members>

2038

2039

* You must have a GPG key registered to your Launchpad account.

2040

2041

* Configure ``dput`` to upload to our PPA with this section in your

2042

``~/.dput.cf``::

2043

2044

[bzr-ppa]

2045

fqdn = ppa.launchpad.net

2046

method = ftp

2047

incoming = ~bzr/ubuntu

2048

login = anonymous

2049

allow_unsigned_uploads = 0

2050

2051

* You need a Ubuntu (or probably Debian) machine, and ::

2052

2053

sudo apt-get install build-essential devscripts dput

2054

2055

Here is the process; there are some steps which should be automated in

2056

future:

2057

2058

#. You will need a working directory for each supported release, such as

2059

``~/bzr/Packaging/dapper``

2060

2061

#. Download the official tarball of the release to e.g. ``~/bzr/Releases``

2062

2063

#. Copy the original tarball into your per-disto directory, then untar it

2064

and if necessary rename it::

2065

2066

cp -l ~/bzr/Releases/bzrtools-1.3.0.tar.gz bzrtools_1.3.0.orig.tar.gz

2067

tar xfvz bzrtools_1.3.0.orig.tar.gz

2068

mv bzrtools bzrtools-1.3.0

2069

2070

#. Change into that directory and check out the packaging branch::

2071

2072

cd bzrtools

2073

bzr checkout \

2074

bzr+ssh://bazaar.launchpad.net/~bzr/bzrtools/packaging-dapper \

2075

debian

2076

2077

#. For Bazaar plugins, change the ``debian/control`` file to express a

2078

dependency on the correct version of ``bzr``.

2079

2080

For bzrtools this is typically::

2081

2082

Build-Depends-Indep: bzr (>= 1.3~), rsync

2083

Depends: ${python:Depends}, bzr (>= 1.3~), bzr (<< 1.4~), patch

2084

2085

#. Make a new ``debian/changelog`` entry for the new release,

2086

either by using ``dch`` or just editing the file::

2087

2088

dch -v '1.3.0-1~bazaar1~dapper1' -D dapper

2089

2090

dch will default to the distro you're working in and this isn't checked

2091

against the version number (which is just our conversion), so make sure

2092

to specify it.

2093

2094

Release candidates must insert a tilde to make them sort before the

2095

final release, like this: ``bzr-1.4~rc2-1~bazaar1~dapper1``.

2096

2097

Make sure you have the correct email address for yourself, version

2098

number, and distribution. It should look something like this::

2099

2100

> bzrtools (1.3.0-1~bazaar1~dapper1) dapper; urgency=low

2101

>

2102

> * New upstream release.

2103

>

2104

> -- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100

2105

2106

If you need to upload the package again to fix a problem, normally you

2107

should increment the last number in the version number, following the

2108

distro name. Make sure not to omit the initial ``-1``, and make sure

2109

that the distro name in the version is consistent with the target name

2110

outside the parenthesis.

2111

2112

#. Commit these changes into the packaging branch::

2113

2114

bzr ci -m '1.3.0-1~bazaar1~dapper1: New upstream release.' debian

2115

2116

#. Build a source package::

2117

2118

debuild -S -sa -i

2119

2120

This will create a ``.changes`` file in the per-distro directory,

2121

and should invoke gpg to sign it with your key.

2122

Check that file is reasonable: it should be uploading to the intended

2123

distribution, have a .orig file included, and the right version number.

2124

2125

#. Upload into the PPA::

2126

2127

dput bzr-ppa ../bzrtools__1.3.0-1\~bazaar1\~dapper1_source.changes

2128

2129

Don't forget the ``bzr-ppa`` component or dput will try to upload into

2130

the main archive by default. You can disable this by adding this

2131

section to your ``.dput.cf``::

2132

2133

[ubuntu]

2134

fqdn = SPECIFY.A.PPA.NAME

2135

2136

#. You should soon get an "upload accepted" mail from Launchpad, which

2137

means that your package is waiting to be built. You can then track its

2138

progress in <https://launchpad.net/~bzr/+archive> and

2139

<https://launchpad.net/~bzr/+archive/+builds>.

2140

2141

1761

2142

1762

..

2143

1763

vim: ft=rst tw=74 ai