cartodb/crankshaft
1
0
Fork 0
mirror of https://github.com/CartoDB/crankshaft.git synced 2024-11-01 10:20:48 +08:00
Code Issues Packages Projects Releases Wiki Activity
70 Commits 94 Branches 23 Tags 3.1 MiB
Python 65.5%
PLpgSQL 32.7%
Jupyter Notebook 1.6%
4903af6cdc
Go to file
Javier Goizueta 4903af6cdc Add existing release 0.0.1 
The existing 0.0.1 files are placed into their location in release/
2016-03-16 18:41:49 +01:00
doc Directory reorganization and sketch of new versioning procedure 2016-03-08 19:35:02 +01:00
release Add existing release 0.0.1 2016-03-16 18:41:49 +01:00
src Change version function from IMMUTABLE to STABLE 2016-03-16 17:09:50 +01:00
.gitignore Fix .pyc files need not only be ignored inside src/py 2016-03-16 11:13:26 +01:00
CONTRIBUTING.md Fixes to the documentation 2016-03-16 18:18:59 +01:00
LICENSE Add licencse 2016-02-15 18:36:38 +01:00
Makefile Add missing Makefile comment 2016-03-16 15:54:39 +01:00
Makefile.global Refactor the Makefile 2016-03-16 15:40:40 +01:00
NEWS.md Release tasks using release-specific virtual environments 2016-03-15 18:48:46 +01:00
README.md Fixes to the documentation 2016-03-16 18:18:59 +01:00
RELEASE.md Reorganize the documentation into separate files 2016-03-16 17:42:28 +01:00

README.md

crankshaft

CartoDB Spatial Analysis extension for PostgreSQL.

Code organization

  • doc documentation
  • src source code
    • src/pg contains the PostgreSQL extension source code
    • src/py Python module source code
  • release reseleased versions
  • env base directory for Python virtual environments

Requirements

  • pip, virtualenv, PostgreSQL
  • python-scipy system package (see src/py/README.md)

Working Process -- Quickstart Guide

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.

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.

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.

Development Guidelines

For a detailed description of the development process please see the CONTRIBUTING.md guide.

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.

Tests, documentation and peer code reviewing are required for all modifications.

The tests (both for SQL and Pyhton) are executed by running, from the top directory:

sudo make install
make test

To request a new release, which will be handled by them release manager, a Pull Request must be created in the develop branch.

Release

The release and deployment process is described in the RELEASE.md guide and it is the responsibility of the designated release manager.