| ... |
... |
@@ -1234,6 +1234,8 @@ This will give you a ``doc/build/html`` directory with the html docs which |
|
1234
|
1234
|
you can view in your browser locally to test.
|
|
1235
|
1235
|
|
|
1236
|
1236
|
|
|
|
1237
|
+.. _contributing_session_html:
|
|
|
1238
|
+
|
|
1237
|
1239
|
Regenerating session html
|
|
1238
|
1240
|
'''''''''''''''''''''''''
|
|
1239
|
1241
|
The documentation build will build the session files if they are missing,
|
| ... |
... |
@@ -1252,6 +1254,8 @@ To force rebuild session html while building the doc, simply run `tox` with the |
|
1252
|
1254
|
env BST_FORCE_SESSION_REBUILD=1 tox -e docs
|
|
1253
|
1255
|
|
|
1254
|
1256
|
|
|
|
1257
|
+.. _contributing_man_pages:
|
|
|
1258
|
+
|
|
1255
|
1259
|
Man pages
|
|
1256
|
1260
|
~~~~~~~~~
|
|
1257
|
1261
|
Unfortunately it is quite difficult to integrate the man pages build
|
| ... |
... |
@@ -1779,3 +1783,244 @@ changing the ``.in`` file, run the following to update the matching ``.txt`` |
|
1779
|
1783
|
file::
|
|
1780
|
1784
|
|
|
1781
|
1785
|
make -C requirements
|
|
|
1786
|
+
|
|
|
1787
|
+
|
|
|
1788
|
+Making releases
|
|
|
1789
|
+---------------
|
|
|
1790
|
+This is a checklist of activities which must be observed when creating
|
|
|
1791
|
+BuildStream releases, it is important to keep this section up to date
|
|
|
1792
|
+whenever the release process changes.
|
|
|
1793
|
+
|
|
|
1794
|
+
|
|
|
1795
|
+Requirements
|
|
|
1796
|
+~~~~~~~~~~~~
|
|
|
1797
|
+There are a couple of requirements and accounts required in order
|
|
|
1798
|
+to publish a release.
|
|
|
1799
|
+
|
|
|
1800
|
+* Ability to send email to ``buildstream-list gnome org`` and
|
|
|
1801
|
+ to ``gnome-announce-list gnome org``.
|
|
|
1802
|
+
|
|
|
1803
|
+* Shell account at ``master.gnome.org``.
|
|
|
1804
|
+
|
|
|
1805
|
+* An email client which still knows how to send emails in plain text.
|
|
|
1806
|
+
|
|
|
1807
|
+
|
|
|
1808
|
+Pre-release changes
|
|
|
1809
|
+~~~~~~~~~~~~~~~~~~~
|
|
|
1810
|
+Before actually rolling the release, here is a list of changes which
|
|
|
1811
|
+might need to be done in preparation of the release.
|
|
|
1812
|
+
|
|
|
1813
|
+* Ensure that the man pages are up to date
|
|
|
1814
|
+
|
|
|
1815
|
+ The man pages are committed to the repository because we are
|
|
|
1816
|
+ currently unable to integrate this generation into the setuptools
|
|
|
1817
|
+ build phase, as outlined in issue #8.
|
|
|
1818
|
+
|
|
|
1819
|
+ If any of the user facing CLI has changed, or if any of the
|
|
|
1820
|
+ related docstrings have changed, then you should
|
|
|
1821
|
+ :ref:`regenerate the man pages <contributing_man_pages>` and
|
|
|
1822
|
+ add/commit the results before wrapping a release.
|
|
|
1823
|
+
|
|
|
1824
|
+* Ensure the documentation session HTML is up to date
|
|
|
1825
|
+
|
|
|
1826
|
+ The session HTML files are committed to the repository for multiple
|
|
|
1827
|
+ reasons, one of them being that the documentation must be buildable
|
|
|
1828
|
+ from within a release build environment so that downstream distribution
|
|
|
1829
|
+ packagers can easily create the docs package.
|
|
|
1830
|
+
|
|
|
1831
|
+ This is currently only needed for the first stable release
|
|
|
1832
|
+ in a stable line of releases, after this point the API is frozen
|
|
|
1833
|
+ and will not change for the remainder of the stable release lifetime,
|
|
|
1834
|
+ so nothing interesting will have changed in these session files.
|
|
|
1835
|
+
|
|
|
1836
|
+ If regeneration is needed, follow :ref:`the instructions above <contributing_session_html>`.
|
|
|
1837
|
+
|
|
|
1838
|
+* Ensure the NEWS entry is up to date and ready
|
|
|
1839
|
+
|
|
|
1840
|
+ For a stable release where features have not been added, we
|
|
|
1841
|
+ should at least add some entries about the issues which have
|
|
|
1842
|
+ been fixed since the last stable release.
|
|
|
1843
|
+
|
|
|
1844
|
+ For development releases, it is worthwhile going over the
|
|
|
1845
|
+ existing entries and ensuring all the major feature additions
|
|
|
1846
|
+ are mentioned and there are no redundancies.
|
|
|
1847
|
+
|
|
|
1848
|
+* Push pre-release changes
|
|
|
1849
|
+
|
|
|
1850
|
+ Now that any final pre-release changes to generated files or NEWS have
|
|
|
1851
|
+ been made, push these directly to the upstream repository.
|
|
|
1852
|
+
|
|
|
1853
|
+ Do not sit around waiting for CI or approval, these superficial changes
|
|
|
1854
|
+ do not affect CI and you are intended to push these changes directly
|
|
|
1855
|
+ to the upstream repository.
|
|
|
1856
|
+
|
|
|
1857
|
+
|
|
|
1858
|
+Release process
|
|
|
1859
|
+~~~~~~~~~~~~~~~
|
|
|
1860
|
+
|
|
|
1861
|
+* Ensure that the latest commit is passing in CI
|
|
|
1862
|
+
|
|
|
1863
|
+ Of course, we do not release software which does not pass it's own
|
|
|
1864
|
+ tests.
|
|
|
1865
|
+
|
|
|
1866
|
+* Get the list of contributors
|
|
|
1867
|
+
|
|
|
1868
|
+ The list of contributors for a given list is a list of
|
|
|
1869
|
+ any contributors who have landed any patches since the
|
|
|
1870
|
+ last release.
|
|
|
1871
|
+
|
|
|
1872
|
+ An easy way to get this list is to ask git to summarize
|
|
|
1873
|
+ the authors of commits since the *last release tag*. For
|
|
|
1874
|
+ example, if we are about to create the ``1.1.1`` release, then
|
|
|
1875
|
+ we need to observe all of the commits since the ``1.1.0``
|
|
|
1876
|
+ release:
|
|
|
1877
|
+
|
|
|
1878
|
+ .. code:: shell
|
|
|
1879
|
+
|
|
|
1880
|
+ git shortlog -s 1.1.0...@
|
|
|
1881
|
+
|
|
|
1882
|
+ At times, the same contributor might make contributions from different
|
|
|
1883
|
+ machines which they have setup their author names differently, you
|
|
|
1884
|
+ can see that some of the authors are actually duplicates, then
|
|
|
1885
|
+ remove the duplicates.
|
|
|
1886
|
+
|
|
|
1887
|
+* Start composing the release announcement email
|
|
|
1888
|
+
|
|
|
1889
|
+ The first thing to do when composing the release email is to
|
|
|
1890
|
+ ensure your mail client has disabled any HTML formatting and will
|
|
|
1891
|
+ safely use plain text only.
|
|
|
1892
|
+
|
|
|
1893
|
+ Try to make the release announcement consistent with other release
|
|
|
1894
|
+ announcements as much as possible, an example of the email
|
|
|
1895
|
+ can be `found here <https://mail.gnome.org/archives/buildstream-list/2019-February/msg00039.html>`_.
|
|
|
1896
|
+
|
|
|
1897
|
+ The recipients of the email are ``buildstream-list gnome org`` and
|
|
|
1898
|
+ ``gnome-announce-list gnome org`` and the title of the email should
|
|
|
1899
|
+ be of the form: ``BuildStream 1.1.1 released``, without any exclamation point.
|
|
|
1900
|
+
|
|
|
1901
|
+ The format of the email is essentially::
|
|
|
1902
|
+
|
|
|
1903
|
+ Hi all,
|
|
|
1904
|
+
|
|
|
1905
|
+ This is the personalized message written to you about this
|
|
|
1906
|
+ release.
|
|
|
1907
|
+
|
|
|
1908
|
+ If this is an unstable release, this should include a warning
|
|
|
1909
|
+ to this effect and an invitation to users to please help us
|
|
|
1910
|
+ test this release.
|
|
|
1911
|
+
|
|
|
1912
|
+ This is also a good place to highlight specific bug fixes which
|
|
|
1913
|
+ users may have been waiting for, or highlight a new feature we
|
|
|
1914
|
+ want users to try out.
|
|
|
1915
|
+
|
|
|
1916
|
+
|
|
|
1917
|
+ What is BuildStream ?
|
|
|
1918
|
+ =====================
|
|
|
1919
|
+ This is a concise blurb which describes BuildStream in a couple of
|
|
|
1920
|
+ sentences, and is taken from the the README.rst.
|
|
|
1921
|
+
|
|
|
1922
|
+ The easiest thing is to just copy this over from the last release email.
|
|
|
1923
|
+
|
|
|
1924
|
+
|
|
|
1925
|
+ =================
|
|
|
1926
|
+ buildstream 1.1.1
|
|
|
1927
|
+ =================
|
|
|
1928
|
+ This section is directly copy pasted from the top of the NEWS file
|
|
|
1929
|
+
|
|
|
1930
|
+
|
|
|
1931
|
+ Contributors
|
|
|
1932
|
+ ============
|
|
|
1933
|
+ - This is Where
|
|
|
1934
|
+ - You Put
|
|
|
1935
|
+ - The Contributor
|
|
|
1936
|
+ - Names Which
|
|
|
1937
|
+ - You Extracted
|
|
|
1938
|
+ - Using git shortlog -s
|
|
|
1939
|
+
|
|
|
1940
|
+
|
|
|
1941
|
+ Where can I get it ?
|
|
|
1942
|
+ ====================
|
|
|
1943
|
+ https://download.gnome.org/sources/BuildStream/1.1/
|
|
|
1944
|
+
|
|
|
1945
|
+ For more information on the BuildStream project, visit our home page
|
|
|
1946
|
+ at https://buildstream.build/
|
|
|
1947
|
+
|
|
|
1948
|
+* Publish the release tag
|
|
|
1949
|
+
|
|
|
1950
|
+ Now that any pre-release changes are upstream, create and push the
|
|
|
1951
|
+ signed release tag like so:
|
|
|
1952
|
+
|
|
|
1953
|
+ .. code:: shell
|
|
|
1954
|
+
|
|
|
1955
|
+ git tag -s 1.1.1
|
|
|
1956
|
+ git push origin 1.1.1
|
|
|
1957
|
+
|
|
|
1958
|
+* Upload the release tarball
|
|
|
1959
|
+
|
|
|
1960
|
+ First get yourself into a clean repository state, ensure that you
|
|
|
1961
|
+ don't have any unfinished work or precious, uncommitted files lying
|
|
|
1962
|
+ around in your checkout and then run:
|
|
|
1963
|
+
|
|
|
1964
|
+ .. code:: shell
|
|
|
1965
|
+
|
|
|
1966
|
+ git clean -xdff
|
|
|
1967
|
+
|
|
|
1968
|
+ Create the tarball with the following command:
|
|
|
1969
|
+
|
|
|
1970
|
+ .. code:: shell
|
|
|
1971
|
+
|
|
|
1972
|
+ python3 setup.py sdist
|
|
|
1973
|
+
|
|
|
1974
|
+ And upload the resulting tarball to the master GNOME server:
|
|
|
1975
|
+
|
|
|
1976
|
+ .. code::
|
|
|
1977
|
+
|
|
|
1978
|
+ scp dist/BuildStream-1.1.1.tar.gz <user>@master.gnome.org:
|
|
|
1979
|
+
|
|
|
1980
|
+ And finally login to your account at ``master.gnome.org`` and run
|
|
|
1981
|
+ the install scripts to publish the tarball and update the mirrors:
|
|
|
1982
|
+
|
|
|
1983
|
+ .. code::
|
|
|
1984
|
+
|
|
|
1985
|
+ ftpadmin install BuildStream-1.1.1.tar.gz
|
|
|
1986
|
+
|
|
|
1987
|
+* Send the release email
|
|
|
1988
|
+
|
|
|
1989
|
+ Now that the release tag is up and the tarball is published,
|
|
|
1990
|
+ you can send the release email.
|
|
|
1991
|
+
|
|
|
1992
|
+
|
|
|
1993
|
+Post-release activities
|
|
|
1994
|
+~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
1995
|
+Once the release has been published, there are some activities
|
|
|
1996
|
+which need to be done to ensure everything is up to date.
|
|
|
1997
|
+
|
|
|
1998
|
+* Update the topic line in the #buildstream IRC channel if needed
|
|
|
1999
|
+
|
|
|
2000
|
+ The IRC channel usually advertizes the latest stable release
|
|
|
2001
|
+ in the topic line, now is the right time to update it.
|
|
|
2002
|
+
|
|
|
2003
|
+* Update the website repository
|
|
|
2004
|
+
|
|
|
2005
|
+ The website wants to link to release announcements, but this
|
|
|
2006
|
+ cannot be automated because we cannot guess what the link to
|
|
|
2007
|
+ the release email will be in the mailing list archive.
|
|
|
2008
|
+
|
|
|
2009
|
+ Find the URL to the announcement you just published
|
|
|
2010
|
+ `in the mailing list archives <https://mail.gnome.org/archives/buildstream-list/>`_,
|
|
|
2011
|
+ and use that URL to update the ``anouncements.json`` file in the website
|
|
|
2012
|
+ repository.
|
|
|
2013
|
+
|
|
|
2014
|
+ Commit and push this change to the the ``anouncements.json`` file to
|
|
|
2015
|
+ the upstream website repository, and gitlab will take care of automatically
|
|
|
2016
|
+ updating the website accordingly.
|
|
|
2017
|
+
|
|
|
2018
|
+* Regenerate BuildStream documentation
|
|
|
2019
|
+
|
|
|
2020
|
+ In order to update the badges we use in various documentation
|
|
|
2021
|
+ which reflects what is the latest stable releases and the latest
|
|
|
2022
|
+ development snapshots, we simply need to ensure a pipeline runs
|
|
|
2023
|
+ for the master branch in the BuildStream repository.
|
|
|
2024
|
+
|
|
|
2025
|
+ You can do this by using the "Run Pipeline" feature on the
|
|
|
2026
|
+ `pipelines page in the gitlab UI <https://gitlab.com/BuildStream/buildstream/pipelines>`_.
|
