The Trigger developement team is currently a one-man operation led by Jathan McCollum, aka jathanism.
There are several ways to get involved with Trigger:
All contributors will receive proper attribution for their work. We want to give credit where it is due!
If an issue ticket exists for a given issue, please keep all communication in that ticket’s comments. Otherwise, please use whatever avenue of communication works best for you!
Trigger tries very diligently to honor PEP-8, especially (but not limited to!) the following:
While Trigger’s development methodology isn’t set in stone yet, the following items detail how we currently organize the Git repository and expect to perform merges and so forth. This will be chiefly of interest to those who wish to follow a specific Git branch instead of released versions, or to any contributors.
We use semantic versioning. Version numbers should follow this format:
{Major version}.{Minor version}.{Revision number}.{Build number (optional)}
Major releases update the first number, e.g. going from 0.9 to 1.0, and indicate that the software has reached some very large milestone.
For example, the 1.0 release signified a commitment to a medium to long term API and some significant backwards incompatible (compared to the 0.9 series) features. Version 2.0 might indicate a rewrite using a new underlying network technology or an overhaul to be more object-oriented.
Major releases will often be backwards-incompatible with the previous line of development, though this is not a requirement, just a usual happenstance. Users should expect to have to make at least some changes to their settings.py when switching between major versions.
Minor releases, such as moving from 1.0 to 1.1, typically mean that one or more new, large features has been added. They are also sometimes used to mark off the fact that a lot of bug fixes or small feature modifications have occurred since the previous minor release. (And, naturally, some of them will involve both at the same time.)
These releases are guaranteed to be backwards-compatible with all other releases containing the same major version number, so a settings.py that works with 1.0 should also work fine with 1.1 or even 1.9.
The third and final part of version numbers, such as the ‘3’ in 1.0.3, generally indicate a release containing one or more bugfixes, although minor feature modifications may (rarely) occur.
This third number is sometimes omitted for the first major or minor release in a series, e.g. 1.2 or 2.0, and in these cases it can be considered an implicit zero (e.g. 2.0.0).