* 2020-05-16:
- Version 0.07.6
- Improved how the Python module is delivered

* 2020-03-02:
- Version 0.07.5
- Updated the code for the new OPTD data format (Geonames coordinates
have been added)

* 2019-11-10:
- Version 0.07.4
- FindBoost.cmake now supports older CMake versions

* 2019-09-28:
- Version 0.07.3
- OPENTREP_SAMPLE_DIR is now exported

* 2019-09-28:
- Version 0.07.2
- Merged the trunk and releases branches to master, so as to get
  a standard setup
- The default branch is now master
- The versionning scheme follows the one on the releases branch before,
  i.e., the version number is incremented just before tagging
  the Git repository

* 2019-01-16:
- Version 0.07.1
- Improved the release of Python libraries and scripts (e.g.,
following Fedora packaging guidelines, and it works well
with `pipenv`)

* 2018-10-14:
- Version 0.07.0
- Support of several deployment stages (allowing staging new versions
  before activating them in production when QA-cleared)
- Full support of MacOS
- Full revamping of the options for the
  ``opentrep-{indexer,dbmgr,searcher}`` command-line programs,
  supporting server-side deployments
- Full support of the new OpenTravelData data files, which also
  reference non-IATA POR (points of reference). Hence, ICAO-
  and UN/LOCODE-referenced POR may now be indexed

* 2015-06-28:
- Version 0.06.6
- The Python libraries are now installed into standard directory

* 2015-04-19:
- Version 0.06.5
- The POR reference data file has been renamed, from ORI
  to OPTD (standing for Open Travel Data, i.e., the name of the
  project maintaining that file). The new location is now
  http://bit.ly/1FXmQdl, and the file is named optd_por_public.csv.
- When only (IATA, ICAO) codes are used in the query string,
  the POR are retrieved from the underlying database, when existing
  (and from the classical free-text search when no database is
  available).
- The US DOT World Area Code (WAC) has been added to the POR
  reference data file, and is now retrieved by OpenTREP.

* 2014-04-13:
- Version 0.06.1
- Re-wrote the SQL database layer. A new program, namely
  opentrep-dbmgr, to create, update and query the SQL
  database (which can be SQLite3 or MySQL/MariaDB).
  There is still some work to do to use the SQL database
  when only codes are detected within the search string.
- Issue #6 (http://github.com/trep/opentrep/issues/6):
  Many POR are also indexed with collateral types.
  For instance, air bases are also indexed as airports.
- Issue #7 (http://github.com/trep/opentrep/issues/7):
  The punctuation characters are removed. Note that,
  as the Unicode normalisation procedure is used,
  there is still an issue when called from Django
  (for reasons unknown yet).
- Issues #4 (http://github.com/trep/opentrep/issues/4)
  and #8 (http://github.com/trep/opentrep/issues/8):
  Fixed the ORI POR data file
  (http://github.com/opentraveldata/optd/refdata/ORI).

* 2014-02-01:
- Version 0.06.0
- Issue #1 (http://github.com/trep/opentrep/issues/1):
  The search algorithm is now modular.
- Issues #3 (http://github.com/trep/opentrep/issues/3)
  and #5 (http://github.com/trep/opentrep/issues/5):
  POR are now indexed with their associated PageRank value
  (equal to 0.1% when there is no PageRank vallue).
- Latest ORI POR data:
  http://github.com/opentraveldata/optd/blob/trunk/refdata/ORI/ori_por_public.csv

* 2013-03-10:
- Version 0.05.3
- Fixed a bug hindering the new slice and dice algorithm to fully work.
  That latter now seems to fully work.

* 2013-02-16:
- Version 0.05.2
- The new slice and dice algorithm seems to work now. More thorough tests
  are needed.

* 2013-02-16:
- Version 0.05.1
- Updated the source code to the newest format of the ORI-maintained list
  of POR.
- Added the Geonames-derived feature names (e.g., "nce city" now returns
  the POR for the city of Nice, France).

* 2012-10-14:
- Version 0.05.0
- The search and indexation pieces of algorithm have been completely revamped.
  Every multi-word string now gives birth to a new C++ structure, namely
  StringPartition, made of all its partitions in an exhaustive manner.
  All those string partitions are indexed by Xapian. And an independant search
  is performed on every one of those string partitions; a global match, made of
  the combination from several match-based pieces of algorithm, is then
  assigned to every string partition; the best matching string partition is
  then selected.  That new search algorithm allows, among other things,
  to combine several independant matching methods, including heuristic ones.
- The MySQL database is no longer needed. The ORI-maintained list of POR
  (points of reference) is now parsed, thanks to Boost.Spirit v2.
  A copy of that file is kept under the data/por/ sub-directory.

* 2011-11-12:
- Version 0.04.1
- Added pragmas to have the code compatible with the new Soci-3.1.0 version
- Removed any reference to ExtraCC

* 2011-11-01:
- Version 0.04.0
- The build system is now based on CMake (instead of the GNU Autotools)

* 2009-03-29:
- Version 0.03.0
- Now relies on the new SOCI RPM

* 2009-03-22:
- Version 0.02.0
- RPM release for Fedora 10

