Edgewall Software

Checklist of things to do for a release

The release steps are described on this page. For more information on the roadmap and schedule leading up to a release, see the RoadMap page.

Version identification

The major.minor.micro semantic versioning scheme is followed, with guidance from PEP:0440. However, since the major version is rarely incremented, we generally refer to a 1.x release a major release and a 1.x.y release a minor release.

In the event that a critical defect is discovered after a release is made, the micro version number should be incremented and a new minor release created. In the event that a packaging or distribution error results in the need to generate a new package name, a post-release identifier should be added, starting with post1. The post-release identifier is added by editing tag_build in setup.cfg.

For example, a filename cannot be reused when uploading to PyPI more than once, so a post-release is necessary in the event of a packaging or uploading error.

Preparing a minor release 1.x.y

2 weeks before

Announce a string freeze on Trac-dev, so that the translators can catch up with the latest changes.

Update the TracDev/ReleaseTesting page, ask for testers.

1 week before

Prepare the rc1 packages according to the procedure described below in Release steps, test and upload them.

Testing period. Only critical or no risk fixes.

Preparing a major release 1.x

Prepare a stabilization branch

That way, work can continue on trunk.

Things to adapt in the new stable branch:

1 month before

Announce a beta1 / string freeze on Trac-dev.

2 weeks before

Prepare the rc1 packages.

Testing period. Only critical or no risk fixes.

Release steps

Check the t.e.o wiki

Check the source

Wiki related files

  • Verify that TracStandalone#Reference matches current tracd --help.
  • Update browser source TracLinks that point to t.e.o (e.g. trac:browser:branches/1.2-stable) to the latest stable release (*).
    $ grep --color -R -E "trac:(source|browser|repos):" trac/wiki/default-pages/ --exclude=TracChangeLog --exclude=TracLinks
    
  • Verify that trac/wiki/default-pages matches the list of pages in TracProject/DefaultWikiPages.
  • Update RELEASE.rst from wiki TracChangeLog (File is named RELEASE for Trac < 1.2) (*).
  • Sync the wiki.
    $ make update-docs             # 1.2-stable
    $ make update-docs prefix=1.0  # 1.0-stable
    $ make update-docs prefix=1.3  # trunk
    
  • Preview ReST using docutils.
    $ rst2html.py UPGRADE.rst > UPGRADE.html
    $ open UPGRADE.html
    $ rst2html.py INSTALL.rst > INSTALL.html
    $ open INSTALL.html
    

Other repository files

  • Remove extraneous whitespace in Python source files using reindent.
  • Import the translations from Transifex that have no committers.
  • Check the THANKS and AUTHORS files.
  • Check version number in setup.py and trac/__init__.py.
  • Check that the jQuery and jQuery UI version numbers mentioned in the help match the actual ones, see for example r11041.
  • Update copyright year:
  • Check whether there are any eligible changesets that have not been merged into the branch.
  • Compile CoffeeScript files (Trac 1.3.2+): make coffee

Prepare packages

Prerequisites

  • Use Python 2.7.9 or later on Windows.
  • Install Make on Windows. Choosing one of the following is recommended:
  • Install SSH on Windows.
    • PuTTY works well and can be installed by choco install putty.
  • Create a new virtual environment and install the release requirements:
    $ pip install -Ur requirements-release.txt
    

Create dist packages

  • Check out the release branch and prepare to tag:
    $ svn co --depth empty https://svn.edgewall.org/repos/trac/tags
    $ svn cp ^/branches/1.2-stable trac-1.2.3
    
  • Comment out tag_build setting in setup.cfg.
  • Build source archive (tarball) and wheel on Unix:
    $ make release
    
  • Build Windows exe installers on x86 and x64 (x86-64) platforms. The installer should be built using python for the specified architecture.
    > make release
    

Verify installation on target platforms

  • Smoke test:
    • Install directly from dist.
      $ pip install dist/Trac-.whl
      
    • create an environment with trac-admin, test it with tracd.
    • upgrade an environment created with the previous release' trac-admin, test it with tracd.
    • Uninstall and repeat smoke test for sdist:
      $ pip uninstall Trac
      $ pip install dist/Trac-.tar.gz
      

Upload packages

  • Commit the tag directory.
  • Upload the packages to PyPi (*).
    $ twine upload dist/*
    
  • Upload to https://ftp.edgewall.org/pub/trac.
    • Upload to dist in your home directory:
      $ make upload version=...
      
    • SSH to the edgewall server, move the files to the public FTP directory and update the links:
      $ VER=...  # Example: VER=1.3.3
      $ cd /var/ftp/pub/trac
      # For older stable release (e.g. 1.0)
      $ ./make-release.sh $VER 1.0
      # For latest stable release (e.g. 1.2)
      $ ./make-release.sh $VER
      # For dev release
      $ ./make-release.sh $VER dev
      

Finalize the release

  • Close release coordination ticket. (*)
  • Mark the finished milestones as completed (with the completed date preferably being the date that the releases were announced), and change their descriptions from next maintenance/development release to latest maintenance/development release.
    • The next set of milestones should have their descriptions changed to next maintenance/development release.
    • The previous set of milestones should have their descriptions changed to remove the latest maintenance/development release message.
    • Attach copy of translations statistics chart of Transifex to the milestones.
    A Version will be automatically created (milestone_to_version.py is installed).
  • Upgrade the demo sites.

Announce the release

Prepare for development

  • Add a TicketQuery progress bar for the next version on the TracDev/ReleaseNotes page, in the #Overview section (example).
  • Update version number in setup.py and trac/__init__.py.
  • Create a release coordination ticket with keyword release. The Clone button can be used on the previous release coordination ticket to pre-populate the fields.
  • For major releases, update the RoadMap and add a report Active Tickets for 1.x (e.g. {42}).

(*) not for beta or rc releases


See also: ReleaseTesting, RoadMap, TracDev

Last modified 3 months ago Last modified on Sep 20, 2018, 12:07:17 AM
Note: See TracWiki for help on using the wiki.