2016-02-16 01:29:43 +08:00
|
|
|
# crankshaft
|
|
|
|
|
|
|
|
|
|
CartoDB Spatial Analysis extension for PostgreSQL.
|
|
|
|
|
|
|
|
|
|
## Code organization
|
|
|
|
|
|
2016-03-09 02:35:02 +08:00
|
|
|
* *doc* documentation
|
|
|
|
|
* *src* source code
|
|
|
|
|
* - *src/pg* contains the PostgreSQL extension source code
|
|
|
|
|
* - *src/py* Python module source code
|
2016-03-11 02:13:46 +08:00
|
|
|
* *release* reseleased versions
|
2016-03-16 01:48:46 +08:00
|
|
|
* *env* base directory for Python virtual environments
|
2016-02-16 01:29:43 +08:00
|
|
|
|
|
|
|
|
## Requirements
|
|
|
|
|
|
2016-03-09 02:35:02 +08:00
|
|
|
* pip, virtualenv, PostgreSQL
|
2016-03-11 02:13:46 +08:00
|
|
|
* python-scipy system package (see src/py/README.md)
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
# Working Process -- Quickstart Guide
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-17 00:19:21 +08:00
|
|
|
We distinguish two roles regarding the development cycle of crankshaft:
|
|
|
|
|
|
|
|
|
|
* *developers* will implement new functionality and bugfixes into
|
|
|
|
|
the codebase and will request for new releases of the extension.
|
|
|
|
|
* A *release manager* will attend these requests and will handle
|
|
|
|
|
the release process. The release process is sequential:
|
|
|
|
|
no concurrent releases will ever be in the works.
|
|
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
We use the default `develop` branch as the basis for development.
|
|
|
|
|
The `master` branch is used to merge and tag releases to be
|
|
|
|
|
deployed in production.
|
|
|
|
|
|
2016-03-17 00:19:21 +08:00
|
|
|
Developers shall create a new topic branch from `develop` for any new feature
|
|
|
|
|
or bugfix and commit their changes to it and eventually merge back into
|
|
|
|
|
the `develop` branch. When a new release is required a Pull Request
|
|
|
|
|
will be open againt the `develop` branch.
|
|
|
|
|
|
|
|
|
|
The `develop` pull requests will be handled by the release manage,
|
|
|
|
|
who will merge into master where new releases are prepared and tagged.
|
|
|
|
|
The `master` branch is the sole responsibility of the release masters
|
|
|
|
|
and developers must not commit or merge into it.
|
2016-03-16 01:48:46 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
## Development Guidelines
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
For a detailed description of the development process please see
|
|
|
|
|
the CONTRIBUTING.md guide.
|
2016-03-11 02:13:46 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
Any modification to the source code (`src/pg/sql` for the SQL extension,
|
|
|
|
|
`src/py/crankshaft` for the Python package) shall always be done
|
|
|
|
|
in a topic branch created from the `develop` branch.
|
2016-03-17 00:19:21 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
Tests, documentation and peer code reviewing are required for all
|
|
|
|
|
modifications.
|
2016-03-11 02:13:46 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
The tests (both for SQL and Pyhton) are executed by running,
|
|
|
|
|
from the top directory:
|
2016-03-16 01:48:46 +08:00
|
|
|
|
|
|
|
|
```
|
2016-03-17 00:42:28 +08:00
|
|
|
sudo make install
|
|
|
|
|
make test
|
2016-03-16 01:48:46 +08:00
|
|
|
```
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
To request a new release, which will be handled by them
|
|
|
|
|
release manager, a Pull Request must be created in the `develop`
|
|
|
|
|
branch.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
## Release
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-17 00:42:28 +08:00
|
|
|
The release and deployment process is described in the
|
|
|
|
|
RELEASE.md guide and it is the responsibility of the designated
|
|
|
|
|
release manager.
|
