Artem Pavlenko edited this page Aug 16, 2016 · 59 revisions
Clone this wiki locally

Steps for Mapnik Releases



  • Ensure all tests pass (make test)
  • Test Mapnik with INPUT_PLUGINS='' and ensure tests pass for what functionality is available
  • Test with ./configure WARNING_CXXFLAGS="-Wextra" to ensure all problematic warnings are solved or triaged.

Bundled fonts and scons

OPTIONAL: Consider updating Scons-local to latest release: The last SCons update was 2.5.0.

rm -rf scons
unzip -o scons-local-*.zip -d scons/
rm scons-local-*.zip

OPTIONAL: Consider updating DeJaVu Fonts: The last version updated was 2.37

cd fonts
git rm -r dejavu-fonts-ttf-
tar xvf dejavu-fonts-ttf-2.37.tar.bz2
git add dejavu-fonts-ttf-2.37

Make sure to update font paths in demo/c++/rundemo.cpp

Check for new unifont release

Release candidate

OPTIONAL: If it has been > 3 months since the last official release, consider first promoting a release candidate first:

git tag -a v3.0.0-rc1 -m 'Release Candidate 1 for Mapnik v3.0.0'
git push --tags

Pre-tag updates

make uninstall && ./configure && make
MAPNIK_VERSION=`./utils/mapnik-config/mapnik-config --version`
git commit -a -m "setting up for mapnik v${MAPNIK_VERSION} release [skip ci]" 
git push
  • Update CHANGELOG with the git hash of latest commit using the output of:
git describe # take hash after 'g'
  • Then, push change:
git commit -a -m "update CHANGELOG for mapnik v${MAPNIK_VERSION} release [skip ci]"
git push


We use annotated tags below instead of lightweight tags

MAPNIK_VERSION=`mapnik-config --version`
git tag --annotate "v${MAPNIK_VERSION}" -m "tagging v${MAPNIK_VERSION}"
git push --tags
  • Create and upload clean tarball:

Before running this you'll need:

  • The submodules up to date (otherwise the --depth 1 will fail) (TODO: use branches or tags for submodules?)
  • Ability to post to s3://mapnik/dist/. Test like aws s3 ls s3://mapnik/dist/
make release
  • Test the uploaded tarball:
cd /tmp
rm -rf mapnik-v${MAPNIK_VERSION}.tar.bz2
tar xf mapnik-v${MAPNIK_VERSION}.tar.bz2
cd mapnik-v${MAPNIK_VERSION}
./configure && make && make test
sudo pip install epydoc
cd utils/epydoc_config
PYDOCS_DEST="../../../`mapnik-config --version`/api/python/"
mkdir -p $PYDOCS_DEST
cp -r ./mapnik-python-`mapnik-config --version`/* $PYDOCS_DEST/

Post tag updates

  • If there are new styling or datasource options, create a new mapnik-reference entry for the release:

  • Update master branches entries in CHANGELOG from the new release (if relevant, e.g. if you are tagging and releasing a stable release not from the master branch).

If this was a major release and a stable series is likely, now branch it, for example a 2.1.0 release would warrant an immediate 2.1.x branch for a stable series of bugfix releases.

git branch 2.1.x
git checkout 2.1.x
git push origin 2.1.x
git checkout master

Now bump versions again:

make uninstall && ./configure && make install
MAPNIK_VERSION=`mapnik-config --version`
git ci include/mapnik/version.hpp -m "now working on mapnik v${MAPNIK_VERSION} [skip ci]"
git push

Now also repeat the above for any stable branches created.

Finally, create new github milestones for the newly created future release #s.

And create new launchpad PPA for the target release(s) and series at, then add these release PPA's to the list that gets build nightly:


  • Update the download page(pages/downloads.html)
  • Write new blog post with updated release links and links to changelog
  • Push python api docs and update docs/index.markdown


1) Submit pull request for homebrew formula

2) Package binaries for Ubuntu Linux (PPA)

3) Upload Mac/Win binary packages to the s3 bucket:

TODO - currently do not have bandwidth or set process for this. For Mac: In the past @springmeyer created mac easy installer but just recommending homebrew is better now (since they support binaries/bottles). For Windows: is used to create SDK's but we've not yet formalized document how these can be used (those they are viable).

Wiki Post-Release