Diff for "ReleaseChecklist"

Not logged in - Log In / Register

Differences between revisions 8 and 9
Revision 8 as of 2009-01-13 17:00:18
Size: 4009
Editor: kfogel
Comment: Wording change.
Revision 9 as of 2009-02-03 20:58:11
Size: 4336
Editor: ct-gocept
Comment: Annotate the binary egg rule.
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
   * 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    * 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.'']
Line 49: Line 49:
   * pythonX.Z setup.py bdist_egg upload -s    * pythonX.Z setup.py bdist_egg upload -s 

Release Checklist

Releasing a new package (whether part of Launchpad or not) involves many of the same steps each time. Barry knows more about them than almost anyone, so he's going to fill in this list :-).

[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:

  • 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 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.

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
  • ...
  • Ping Matt R or whoever's appropriate in Canonical, in case there are any special announcement needs for this release.
  • 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)