Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Fixing some FIXMEs in howto-release-django. Refs #20082

  • Loading branch information...
1 parent 6a6bb16 commit ec5dc0010c30f9ca7e9294b97e909f5b47ac1683 @andrewgodwin andrewgodwin committed
Showing with 41 additions and 8 deletions.
  1. +41 −8 docs/internals/howto-release-django.txt
49 docs/internals/howto-release-django.txt
@@ -183,13 +183,46 @@ OK, this is the fun part, where we actually push out a release!
$ md5sum dist/Django-*
$ sha1sum dist/Django-*
- *FIXME: perhaps we should switch to sha256?*
#. Create a "checksums" file containing the hashes and release information.
- You can start with `a previous checksums file`__ and replace the
- dates, keys, links, and checksums. *FIXME: make a template file.*
+ Start with this template and insert the correct version, date, release URL
+ and checksums::
+ This file contains MD5 and SHA1 checksums for the source-code tarball
+ of Django <<VERSION>>, released <<DATE>>.
+ To use this file, you will need a working install of PGP or other
+ compatible public-key encryption software. You will also need to have
+ the Django release manager's public key in your keyring; this key has
+ the ID ``0x3684C0C08C8B2AE1`` and can be imported from the MIT
+ keyserver. For example, if using the open-source GNU Privacy Guard
+ implementation of PGP::
+ gpg --keyserver --recv-key 0x3684C0C08C8B2AE1
+ Once the key is imported, verify this file::
+ gpg --verify <<THIS FILENAME>>
+ Once you have verified this file, you can use normal MD5 and SHA1
+ checksumming applications to generate the checksums of the Django
+ package and compare them to the checksums listed below.
+ Release package:
+ ================
+ Django <<VERSION>>:<<URL>>
+ MD5 checksum:
+ =============
+ SHA1 checksum:
+ ==============
- __
#. Sign the checksum file (``gpg --clearsign
Django-<version>.checksum.txt``). This generates a signed document,
@@ -268,8 +301,7 @@ Now you're ready to actually put the release out there. To do this:
of the docs by flipping the ``is_default`` flag to ``True`` on the
appropriate ``DocumentRelease`` object in the ````
database (this will automatically flip it to ``False`` for all
- others). *FIXME: I had to do this via fab managepy:shell,docs but we should
- probably make it possible to do via the admin.*
+ others); you can do this using the site's admin.
#. Post the release announcement to the django-announce,
django-developers and django-users mailing lists. This should
@@ -289,7 +321,8 @@ You're almost done! All that's left to do now is:
``stable/1.?.x`` git branch), you'll want to create a new
``DocumentRelease`` object in the ```` database for
the new version's docs, and update the ``docs/fixtures/doc_releases.json``
- JSON fixture. *FIXME: what is the purpose of maintaining this fixture?*
+ JSON fixture, so people without access to the production DB can still
+ run an up-to-date copy of the docs site.
#. Add the release in `Trac's versions list`_ if necessary. Not all versions
are declared; take example on previous releases.

0 comments on commit ec5dc00

Please sign in to comment.
Something went wrong with that request. Please try again.