Skip to content

Releases

Changelog

This document describes how we release uMap.

If you are looking for the releases changelog, please go there.

How to make a release

  1. Run tests:
    • make test
  2. I18N
    • make messages look for new strings within the code
    • make tx_push to publish new strings to transifex
    • translators at work
    • make tx_pull to retrieve new translations from transifex
    • make compilemessages to create regular .mo + umap/static/umap/locale/*.js
    • commit new translations git commit -am "i18n"
  3. Test collectstatic: umap collectstatic --no-input
  4. Bump version: make patch|minor
  5. git commit -am "1.X.Y"
  6. git tag 1.X.Y
  7. git push && git push --tag
  8. Go to Github release page and Generate release notes + paste it in docs/changelog.md + finish Github process for a new release
  9. Commit the changelog git commit -am "changelog"
  10. make build
  11. make publish
  12. make docker

Deploying instances

OSMfr

We use a custom flat Makefile, versioned here.

To deploy a new version on the dev server:

  • edit the .env.dev file and change the version number
  • run this command FLAVOUR=dev make deploy

To deploy a new version on OSM France servers:

  • edit the .env.osmfr file and change the version number
  • run this command FLAVOUR=osmfr make deploy

ANCT

Update the Dockerfile with correct version and put a tag YYYY.MM.DD in order to deploy it to production.

When to make a release

We aim to support Baseline “Widely available” (implemented in major browsers within the last 30 months).

Major (2.Y.Z)

  • when we bump Django to a major version
  • when we change how we store data (both in database and filesystem)

Minor (X.3.Z)

  • when we add new features
  • when we improve an existing feature
  • when we improve the usability
  • when we change templates

If it's not a major nor a patch, it's a minor.

Patch (X.Y.12)

  • when there are bugfixes