You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dgranda edited this page Jul 18, 2012
·
1 revision
Some guidelines when contributing to pytrainer
Development Environment
To set up the pytrainer development environment, simply clone the Git repository hosted at [GitHub] (https://github.com/pytrainer/pytrainer) and make sure all required dependencies are installed on your system. The dependencies are listed in the INSTALL file.
pytrainer can be executed from source by executing bin/pytrainer. By default pytrainer will use ~/.pytrainer as its data directory. To avoid corrupting your live pytrainer data it is strongly recommended that you run your development version using a non-standard data directory by supplying the --confdir startup parameter.
All unit tests can be executed by running nosetests from the project root.
Best Practices
DRY: Don't Repeat Yourself!
all business logic must be unit tested
don't commit commented-out code
don't commit print statements
avoid committing white space changes
always use one short summary sentence as first paragraph of commit message
the last line of a commit message should contain a ticket reference in the form: ticket:<ticket_number>.
TODO elaborate and expand on these points
Version Numbering Scheme
pytrainer uses Semantic Versioning. This means the version number of a release contains three meaningful integer components: major, minor, and service pack. These are explained in the following table:
Version Component
Incremented to indicate
Major
there has been a significant fundamental change or rewrite since the previous release
Minor
a new feature has been added since the previous release
Service Pack
only bugs have been fixed since the previous release
The release scheduling is very dynamic so the version number is incremented on an as-needed basis. A scheduled release may plan to contain only bug fixes but new features may be added to a release due to submitted patches etc. The version number of the release should be modified to reflect this when that happens. For example, the 1.7.3 service pack release may be renamed to 1.8.0 because a new feature was added.
Releases are generally only made from the master branch. If a release is necessary while new feature development is ongoing on the master branch then a new maintenance branch should be created from the previous tagged release. The maintenance branch will contain bug fix commits that are cherry picked from master or later merged on to master.
#File Formats
Internally pytrainer stores information as XML files conforming to the GPX schema with extensions conforming to the Cluetrust schema (including lap information)
pytrainer also stores summary information in a database.
The GPX+Cluetrust file format is sometimes referred to as GPX+ on the development mail lists.