Edgewall Software

Version 164 (modified by figaro, 14 months ago) ( diff )

Add page outline and ReadTheDocs reference

Contents

  1. Version identification
  2. Preparing a minor release 1.x.y
    1. 2 weeks before
    2. 1 week before
  3. Preparing a major release 1.x
    1. Prepare a stabilization branch
    2. 1 month before
    3. 2 weeks before
  4. Release steps
    1. Check the t.e.o wiki
    2. Check the source
      1. Wiki related files
      2. Other repository files
    3. Prepare packages
      1. Prerequisites
      2. Verify installation on target platforms
      3. Create dist packages
      4. Publish packages
    4. Finalize the release
    5. Announce the release
    6. Prepare for development

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 defect or packaging distribution error is discovered after a release is made, the micro version number should be incremented and a new minor release created.

A filename cannot be reused when uploading to PyPI ​more than once, so the micro version must be incremented 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​.

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

Create a release coordination ticket

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
  • Update RELEASE.rst​ from wiki TracChangeLog.
  • Sync the wiki. 
    $ make update-help prefix=1.0  # 1.0-stable
$ make update-help prefix=1.2  # 1.2-stable
$ make update-help             # 1.4-stable
$ make update-help prefix=1.5  # trunk (1.5dev)
  • 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

  • Run checks for valid Jinja2 and HTML syntax: 
    $ make jinja jinjaopts=-q
  • Remove extraneous whitespace in Python source files using ​reindent. From the root of the repository: 
    $ reindent -rn .
  • Import the translations from Transifex that have no committers. 
    $ make tx-merge-{bs,cs,da,el,es_MX,et,fa,fi,gl,ko,pl,pt,ro,sq,uk,vi}
$ make update-{bs,cs,da,el,es_MX,et,fa,fi,gl,ko,pl,pt,ro,sq,uk,vi}
$ make {check,compile,stats,summary}-{bs,cs,da,el,es_MX,et,fa,fi,gl,ko,pl,pt,ro,sq,uk,vi}
  • Check the THANKS​ and AUTHORS​ files.
  • Check version number in setup.py​ (setup.cfg​ since 1.5.3) and trac/__init__.py​.
  • Check that the jQuery and jQuery UI version numbers mentioned in the help match the actual ones, see for example r16094. The versions should also match those in JavaScript.
  • Update copyright year: 
    $ make 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

Verify installation on target platforms

  • Build source archive (tarball), wheel and Windows installers: 
    $ make release
  • Smoke test:
    • Install directly from dist or run exe installer. 
      $ 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

Create dist packages

  • Check out the release branch and prepare to tag: 
    $ svn co --depth empty https://svn.edgewall.org/repos/trac/tags trac-tags
$ cd trac-tags
$ svn cp ^/branches/1.2-stable trac-1.2.3
$ cd trac-1.2.3
  • Delete the tag_build section at the top of setup.cfg​.
  • Commit the tag directory.
  • Build Windows exe installers on x86 and x64 (x86-64) platforms. The installer should be built using ​python for the specified architecture. 
    > make release
  • Upload to ​https://ftp.edgewall.org/pub/trac. 
    $ make upload version=...

Publish packages

SSH to the edgewall server and run script that copies the files, creates links for TracDownload and publishes to PyPI: 

$ VER=...  # Example: VER=1.3.3
$ cd /var/ftp/pub/trac
# For 1.0-stable release
$ sudo ./make-release.sh $VER 1.0
# For 1.2-stable release
$ sudo ./make-release.sh $VER 1.2
# For 1.4-stable release (the latest stable)
$ sudo ./make-release.sh $VER
# For 1.5dev release
$ sudo ./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 Stable Release or Preview Release version numbers on the ​Wikipedia page, as appropriate.
    1. Click on the Pencil icon to navigate to the wikidata page.
    2. Select Add Value at the bottom of the software version identifier table and add a new entry.
      1. Follow the pattern for existing entries, adding version type, publication date, and references.
      2. Set the Rank to preferred. The Rank is the up/circle/down icon to the left of the input box for the version identifier.
      3. Set the Rank for the older version to normal.
  • Check whether the ​ReadTheDocs reference is up to date: Short URLs must point to latest versions.

Prepare for development

(*) not for beta or rc releases

See also: ReleaseTesting, RoadMap, TracDev

Note: See TracWiki for help on using the wiki.