Version 115 (modified by 6 years ago) ( diff ) | ,
---|
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
- Update the TracChangeLog page.
- Verify TracInstall and TracUpgrade.
- For major releases:
- Check TracDev/ReleaseNotes, go through the tickets which have an empty Release Notes field and say a word there.
- Check TracDev/ApiChanges.
Check the source
Wiki related files
- Verify that TracStandalone#Reference matches current
tracd --help
. - Verify that trac/wiki/default-pages matches the list of pages in TracProject/DefaultWikiPages.
- Sync the wiki.
- Update RELEASE.rst from wiki TracChangeLog (File is named
RELEASE
for Trac < 1.2). - Sync UPGRADE.rst and INSTALL.rst from the wiki using contrib/wiki2rst.py (Files are named
UPGRADE
andINSTALL
for Trac < 1.2).$ ./contrib/wiki2rst.py TracUpgrade > UPGRADE.rst $ ./contrib/wiki2rst.py TracInstall > INSTALL.rst
- 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, trac/wiki/default-pages/WikiStart, 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 on about page and COPYING file.
- Check whether there are any eligible changesets that have not been merged into the branch.
- Comment out
tag_build
setting in setup.cfg.
Prepare packages
Prerequisites
- Use Python 2.7.9 or later on Windows.
- Create a new virtual environment and install the release requirements:
$ pip install -Ur requirements-release.txt
Create dist packages
- Check out the release branch.
- 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
- Install in a new virtual environment.
- Smoke test:
- create an environment with
trac-admin
, test it withtracd
- upgrade an environment created with the previous release'
trac-admin
, test it withtracd
- create an environment with
Upload packages
- Upload the packages to PyPi (*).
$ twine upload dist/*
- Upload to https://ftp.edgewall.org/pub/trac.
- Upload to
dist
in your home directory usingmake upload version=...
- Move the files to
/var/ftp/pub/trac
- Run
update_latest.sh
in/var/ftp/pub/trac
.- For stable release:
./update_latest <version>
- For dev release:
./update_latest <version> dev
- For stable release:
- Upload to
Finalize the release
- Test
easy_install Trac
. - Tag/copy version in subversion.
- Update TracDownload.
- 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.
Announce the release
- Post to the following channels:
- trac-users, trac-dev (all releases)
- trac-announce, #TracProject, python-announce (
python-announce-list@python.org
)
- 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
- Uncomment
tag_build
setting in setup.cfg. - Update version number in setup.py, trac/wiki/default-pages/WikiStart, 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.
- Update the Current target releases.
- 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