453a242e6a
Just to test it before running it in the servers.
2.4 KiB
2.4 KiB
Releases
!!! info "Changelog"
This document describes how we release uMap.
If you are looking for the releases changelog, [please go there](changelog.md).
How to make a release
- Run tests:
make test
make testjs
- I18N
make messages
look for new strings within the codemake tx_push
to publish new strings to transifex- translators at work
make tx_pull
to retrieve new translations from transifexmake compilemessages
to create regular.mo
+umap/static/umap/locale/*.js
- commit new translations
git commit -am "i18n"
- Test collectstatic:
umap collectstatic --no-input
- Bump version:
make patch|minor
git commit -am "1.X.Y"
git tag 1.X.Y
git push && git push --tag
- Go to Github release page and Generate release notes + paste it in
docs/changelog.md
+ finish Github process for a new release - Commit the changelog
git commit -am "changelog"
make build
make publish
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