not add your bugs to closed issues. They may looks similar to you but
often are completely different from the maintainer's point of view.
-### When Reporting Bad Search Results...
-
-Please make sure to add the following information:
-
- * the URL of the query that produces the bad result
- * the result you are getting
- * the expected result, preferably a link to the OSM object you want to find,
- otherwise an address that is as precise as possible
-
-To get the link to the OSM object, you can try the following:
-
- * go to https://openstreetmap.org
- * zoom to the area of the map where you expect the result and
- zoom in as much as possible
- * click on the question mark on the right side of the map,
- then with the queston cursor on the map where your object is located
- * find the object of interest in the list that appears on the left side
- * click on the object and report the URL back that the browser shows
-
-### When Reporting Bugs...
-
-Please add the following information to your issue:
-
- * hardware configuration: RAM size, CPUs, kind and size of disks
- * Operating system (also mention if you are running on a cloud service)
- * Postgres and Postgis version
- * list of settings you changed in your Postgres configuration
- * Nominatim version (release version or,
- if you run from the git repo, the output of `git rev-parse HEAD`)
- * (if applicable) exact command line of the command that was causing the issue
-
-Bug reports that do not include extensive information about your system,
-about the problem and about what you have been trying to debug the problem
-will be closed.
-
## Workflow for Pull Requests
We love to get pull requests from you. We operate the "Fork & Pull" model
an issue first or comment on the appropriate issue already existing so
that duplicate work can be avoided.
+### Using AI-assisted code generators
+
+PRs that include AI-generated content, may that be in code, in the PR
+description or in documentation need to
+
+1. clearly mark the AI-generated sections as such, for example, by
+ mentioning all use of AI in the PR description, and
+2. include proof that you have run the generated code on an actual
+ installation of Nominatim. Adding and excuting tests will not be
+ sufficient. You need to show that the code actually solves the problem
+ the PR claims to solve.
+
+
## Coding style
Nominatim historically hasn't followed a particular coding style but we
are in process of consolidating the style. The following rules apply:
* Python code uses the official Python style
- * indention
+ * indentation
* SQL use 2 spaces
* all other file types use 4 spaces
* [BSD style](https://en.wikipedia.org/wiki/Indent_style#Allman_style) for braces
* no spaces after opening and before closing bracket
* leave out space between a function name and bracket
but add one between control statement(if, while, etc.) and bracket
- * for PHP variables use CamelCase with a prefixing letter indicating the type
- (i - integer, f - float, a - array, s - string, o - object)
-The coding style is enforced with PHPCS and can be tested with:
+The coding style is enforced with flake8. It can be tested with:
```
- phpcs --report-width=120 --colors .
+make lint
```
## Testing
-Before submitting a pull request make sure that the following tests pass:
+Before submitting a pull request make sure that the tests pass:
```
- cd test/bdd
- behave -DBUILDDIR=<builddir> db osm2pgsql
+ make tests
```
-```
- cd test/php
- phpunit ./
-```
+## Releases
+
+Nominatim follows semantic versioning. Major releases are done for large changes
+that require (or at least strongly recommend) a reimport of the databases.
+Minor releases can usually be applied to existing databases. Patch releases
+contain bug fixes only and are released from a separate branch where the
+relevant changes are cherry-picked from the master branch.
+
+Checklist for releases:
+
+* [ ] increase versions in
+ * `src/nominatim_api/version.py`
+ * `src/nominatim_db/version.py`
+ * CMakeLists.txt
+* [ ] update `ChangeLog` (copy information from patch releases from release branch)
+* [ ] complete `docs/admin/Migration.md`
+* [ ] update EOL dates in `SECURITY.md`
+* [ ] commit and make sure CI tests pass
+* [ ] test migration
+ * download, build and import previous version
+ * migrate using master version
+ * run updates using master version
+* [ ] prepare tarball:
+ * `git clone --recursive https://github.com/osm-search/Nominatim` (switch to right branch!)
+ * `rm -r .git* osm2pgsql/.git*`
+ * copy country data into `data/`
+ * add version to base directory and package
+* [ ] upload tarball to https://nominatim.org
+* [ ] prepare documentation
+ * check out new docs branch
+ * change git checkout instructions to tarball download instructions or adapt version on existing ones
+ * build documentation and copy to https://github.com/osm-search/nominatim-org-site
+ * add new version to history
+* [ ] check release tarball
+ * download tarball as per new documentation instructions
+ * compile and import Nominatim
+ * run `nominatim --version` to confirm correct version
+* [ ] tag new release and add a release on github.com
+* [ ] build pip packages and upload to pypi
projects / nominatim.git / blobdiff