Edgewall Software

Version 135 (modified by Ryan J Ollos, 6 years ago) ( diff )

Minor changes.

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

  • Post to the following channels:
  • Update the version displayed in the #trac IRC channel entry message (*) 
    /msg ChanServ topic #trac "The topic is: https://trac.edgewall.org/ | https://trac-hacks.org/ | Latest version - <version>."
  • Update the ​Wikipedia page, and in particular the version numbers.

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

Note: See TracWiki for help on using the wiki.