Diff for "ReleaseChecklist"

Not logged in - Log In / Register
Differences between revisions 4 and 12 (spanning 8 versions)
⇤ ← Revision 4 as of 2009-01-07 22:43:12 →
Size: 4178
Editor: barry
Comment:
← Revision 12 as of 2011-09-13 14:43:40 → ⇥
Size: 3070
Editor: benji
Comment: Urge the use of sane version numbers.
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 (generally, [[http://www.fsf.org/licensing/licenses/agpl-3.0.html|AGPLv3]] if it's server-side code, [[http://www.fsf.org/licensing/licenses/gpl-3.0.html|GPLv3]] for anything else, but [[http://www.fsf.org/licensing/licenses/lgpl-3.0.html|LGPLv3]] if it needs to be useable in proprietary programs or there is a license incompatibility with the AGPLv3 or GPLv3.)
 * 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 42: Line 25:
   * Meditate upon http://semver.org/
Line 46: Line 30:
   * 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 33:
   * 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.		    * 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:
Line 56: Line 38:
   * Any other appropriate place

== Comments and Open Issues ==

 * How do we go about getting license approval?
   * What exactly are the steps?
   * Who gives the green light/
   * How long can you expect the process to take?
   * What input do you need to get the approval process rolling?		    * 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.

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

    • Meditate upon http://semver.org/

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