innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

We should branch after the first beta. 

We did this for 1.6 and it was very effective. 95%+ of fixes which merge
during the alpha are backported, as the policy is "all but really major
features". It's easier to just not merge any really major features.
After beta, we have feature freeze so we need to backport bugs to stable
but not features, so then the branch makes sense.
This commit is contained in:
Marc Tamlyn 2014-01-23 08:13:29 +00:00
parent 3b869b09d0
commit d7aa0bd802
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/internals/howto-release-django.txt
View File

@ -329,7 +329,7 @@ You're almost done! All that's left to do now is:
example, after releasing 1.5.1, update ``VERSION`` to
``VERSION = (1, 5, 2, 'alpha', 0)``.
#. For the first alpha release of a new version (when we create the
#. For the first beta release of a new version (when we create the
``stable/1.?.x`` git branch), you'll want to create a new
``DocumentRelease`` object in the ``docs.djangoproject.com`` database for
the new version's docs, and update the ``docs/fixtures/doc_releases.json``
@ -340,11 +340,11 @@ You're almost done! All that's left to do now is:
default if it's a final release). Not all versions are declared;
take example on previous releases.
.. _Trac's versions list: https://code.djangoproject.com/admin/ticket/versions
#. On the master branch, remove the ``UNDER DEVELOPMENT`` header in the notes
of the release that's just been pushed out.
.. _Trac's versions list: https://code.djangoproject.com/admin/ticket/versions
Notes on setting the VERSION tuple
==================================