diff --git a/doc/contributing/release-process.rst b/doc/contributing/release-process.rst index 0c5b6d9cd0a..61bbeacaede 100644 --- a/doc/contributing/release-process.rst +++ b/doc/contributing/release-process.rst @@ -15,22 +15,45 @@ new CKAN release. Process overview ---------------- -The process of a new release starts with the creation of a new release branch. -A release branch is the one that will be stabilized and eventually become the actual -released version. Release branches are always named ``release-vM.m.p``, after the -:ref:`major, minor and patch versions ` they include. Major and minor versions are -always branched from master. Patch releases are always branched from the most recent tip -of the previous patch release branch. +.. versionchanged:: 2.6 + +The process of a new release starts with the creation of a new release development branch. +A release development branch is the one that will be stabilized and eventually become the actual +released version. Release branches are always named ``dev-vM.m``, after the +:ref:`major and minor versions ` they include. Major and minor versions are +always branched from master. When the release is actually published a patch version number is added +and the release is tagged in the form ``ckan-M.m.p``. All backports are cherry-picked on the ``dev-vM.m`` branch. + :: - +--+---------------------------------------+-------------> Master - | | - +-----------------> release-v2.4.0 +----------> release-v2.5.0 - | - +---------> release-v2.4.1 - | - +------> release-v2.4.2 + +--+-----------------------------------------+-------------> Master + | | + +-----+-------------+------> dev-v2.6 +-------> dev-v2.7 + | | + ckan-2.6.0 ckan-2.6.1 + + +Additionally, the ``release-vM.m-latest`` branches always contain the latest published released for that version. + + +.. note:: + + Prior to CKAN 2.6, release branches were named ``release-vM.m.p``, after the + :ref:`major, minor and patch versions ` they included, and patch releases + were always branched from the most recent tip of the previous patch release branch + (tags were created with the same convention). + Starting from CKAN 2.6, the convention is the one described above. + + :: + + +--+---------------------------------------+-------------> Master + | | + +-----------------> release-v2.4.0 +----------> release-v2.5.0 + | + +---------> release-v2.4.1 + | + +------> release-v2.4.2 Once a release branch has been created there is generally a three-four week period until the actual release. During this period the branch is tested and fixes cherry-picked. The whole @@ -52,14 +75,14 @@ Turn this file into a github issue with a checklist using this command:: #. Create a new release branch:: - git checkout -b release-v2.5.0 + git checkout -b dev-v2.7 Update ``ckan/__init__.py`` to change the version number to the new version - with a *b* after it, e.g. *2.5.0b*. + with a *b* after it, e.g. *2.7.0b* (Make sure to include 0 as the patch version number). Commit the change and push the new branch to GitHub:: git commit -am "Update version number" - git push origin release-v2.5.0 + git push origin dev-v2.7 You will probably need to update the same file on master to increase the version number, in this case ending with an *a* (for alpha). @@ -388,7 +411,7 @@ a release. a. Go to the `Read The Docs versions page `_ and make the relevant release 'active' (make sure to use the tag, ie ckan-X.Y.Z, - not the branch, ie release-vX.Y.Z). + not the branch, ie dev-vX.Y). b. If it is the latest stable release, set it to be the Default Version and check it is displayed on http://docs.ckan.org. @@ -413,7 +436,7 @@ a release. To find out what i18n commits there are on the release-v* branch that are not on master, do:: - git log master..release-v* ckan/i18n + git log master..dev-v* ckan/i18n Then ``checkout`` the master branch, do a ``git status`` and a ``git pull`` to make sure you have the latest commits on master and no local changes. @@ -432,12 +455,7 @@ Preparing patch releases Often this will be part of the announcement of a CKAN major/minor release. But if patches go out separately then they will need their own announcement. -#. Create a new branch off the existing release branch:: - - git checkout release-v2.5.1 - git checkout -b release-v2.5.2 - - Update ``ckan/__init__.py`` with the incremented patch number e.g. `2.5.1` becomes `2.5.2`. +#. Update ``ckan/__init__.py`` with the incremented patch number e.g. `2.5.1` becomes `2.5.2`. Commit the change and push the new branch to GitHub:: git commit -am "Update version number" @@ -445,8 +463,10 @@ Preparing patch releases #. Cherry-pick PRs marked for back-port. - These are usually marked on Github using a label: https://github.com/ckan/ckan/labels - and remember to look for PRs that are closed i.e. merged. + These are usually marked on Github using the ``Backport Pending`` `labels`_ and the + relevant labels for the versions they should be cherry-picked to (eg ``Backport 2.5.3``). + Remember to look for PRs that are closed i.e. merged. Remove the ``Backport Pending`` label once the + cherry-picking has been done (but leave the version ones). #. Ask the tech team if there are security fixes or other fixes to include. @@ -494,10 +514,10 @@ Doing the patch releases python setup.py sdist upload -#. Merge the patch release branch to the relevant ``release-v2.X-latest`` branch, eg:: +#. Merge the release development branch to the relevant ``release-v2.X-latest`` branch, eg:: - git checkout release-v2.5-latest - git merge release-v2.5.2 + git checkout release-v2.7-latest + git merge dev-v2.7 #. Write a CKAN blog post and announce it to ckan-announce & ckan-dev & twitter. @@ -506,4 +526,5 @@ Doing the patch releases .. _Transifex: https://www.transifex.com/projects/p/ckan .. _`Read The Docs`: http://readthedocs.org/dashboard/ckan/versions/ +.. _labels: https://github.com/ckan/ckan/labels .. _Ansible: http://ansible.com/