Diff for "ReleaseChecklist"

Not logged in - Log In / Register

Differences between revisions 10 and 11
Revision 10 as of 2009-03-31 17:17:10
Size: 4446
Editor: kfogel
Comment: Add reminder to check that data is public.
Revision 11 as of 2011-07-13 03:14:44
Size: 3031
Editor: lifeless
Comment: point at new broken out creating-new-projects page
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
the same steps each time. Barry knows more about them than almost anyone, so
he's going to fill in this list :-).
the same steps each time.
Line 19: Line 18:
 * Check for any proprietary licenses on dependencies. If any, stop at this step and go solve that problem first.
 * Add the appropriate open source license to the project. See [[ChoosingALicense|Choosing A License]].
 * Set up a Launchpad project for it.
 * Use the PythonProjectTemplate (TBD) to create the directory structure for your package. This will include a setup.py and other useful files, such as the HACKING.txt file described below.
 * Edit the default HACKING.txt file. The top of the HACKING.txt file should reference the generic (wiki-based) hacking guidelines, something like this: {{{
      These are guidelines for hacking on the FOOBAR project.
      But first, please see the common hacking guidelines at:

        http://dev.launchpad.net/Hacking

      You should assume the above guidelines are in effect; below, we only
      discuss the ways (if any) in which the FOOBAR project differs from
      or extends those common guidelines.
}}} Any further material in HACKING.txt should be specific guidelines about this project, not about projects in general.
 * Register your project with PyPI: python setup.py register
 * ...
 * Move on to the "all releases" checklist below.
Follow CreatingNewProjects.
Line 50: Line 33:
 *
 * ...
 * Ping Matt R or whoever's appropriate in Canonical, in case there are any special announcement needs for this release.

Release Checklist

Releasing a new package (whether part of Launchpad or not) involves many of the same steps each time.

[BAW: Note that in the fine tradition of PEP 101, you should debug these instructions each time you actually make a release.]

[BAW: Note that the instructions here are pretty specific to releasing Python packages. I think it will make more sense to separate this out based on language, since other languages will have their own way of doing things. I anticipate most of our releases being Python, so that's what I'm describing here.]

First steps

You will want to make sure your Python package is available on the Cheeseshop (a.k.a. Python Package Index or PyPI). You need to register yourself with PyPI so that you can upload packages. I thought you could do this from the command line, but I'm not able to find it. In the meantime:

First release only:

Follow CreatingNewProjects.

All releases (first and subsequent):

  • Make sure your GPG key is publicly available.
  • Bump the version number.
    • Python: this is probably in the setup.py or in package/init.py

  • Update the NEWS.txt file.
    • Hopefully, you've been keeping this up-to-date as you've changed the package. If not, do a bzr log to figure out what's changed. Use the StandardNewsFile format.

  • Tag your branch: bzr tag X.Y.Z (make sure this tag matches what's in your init.py or setup.py file).

  • Build your package and upload it:
    • You will want to build one source distribution and one or more egg distributions. The eggs are Python version specific, you need to do the first command to get the tarball and first egg, and then the subsequent commands for every other Python version you want to support with an egg. I recommend Python 2.4, 2.5, and 2.6. [ctheune: Note that releasing eggs isn't necessary for platforms which regularly have compilers around. For Python-only packages any platform can run from the source distribution. Releasing binary eggs is error prone because of an incomplete discriminator anyway and is a usual source of confusion and avoidable errors.]

    • pythonX.Y setup.py sdist bdist_egg upload -s
    • pythonX.U setup.py bdist_egg upload -s
    • pythonX.Z setup.py bdist_egg upload -s
  • Make sure the project's data in Launchpad is public! Check that you can browse the code branch(es), etc.
  • Announce in appropriate places:
    • python-announce@python.org

    • Your Launchpad project's announce page
    • Any other appropriate place (but coordinate to avoid duplicate announcements).
    Ideally, someone who's active in the relevant community makes the announcement there. The announcements don't have to be in a standardized form, as long as they contain the important information and point back to the project's page. It's better each is written in that announcer's usual "voice", in fact, since the announcer is already known to that community.

ReleaseChecklist (last edited 2011-09-13 14:43:40 by benji)