To keep the repository in good working order, and to ensure that the integrated tools (e.g. [Changelog for Dart][changelog]) work correctly, some restrictions must be placed on development process.

Development Workflow

1. Identify a task in Trello to be completed (in the "Backlog" list) - the tasks are ranked with the most urgent at the top.
2. Move the task to the "Design" list and begin a complete design. A task's design phase is complete once the problem has a clear solution and the areas that must be updated in code are identified.
3. Move the task to the "Implementation" phase. Implementation is complete once the code changes required are completed and thoroughly tested via automated tests and in the example app.
4. Update the CHANGELOG via Cider: $ cider log <type> "message" where the message is the same message you will use to commit the change in git.
5. git commit all the changes (including the CHANGELOG!) and git push origin master to the central repository.
6. Move the task to the "Pending Release" list in Trello.

Release Workflow

Execute a version bump via Cider:

$ cider bump

$ cider version

Tag the repository with the updated version name:

git tag v<version>

Commit all changes to the repository and push. The commit message for the release should read "Released v<version number>":

$ git commit -am "Released v<version>"
$ git push origin master

Push tags:

$ git push origin v<version>

Publish the package to pub.dev:

$ pub publish

Versioning

All versioning must obey Semantic Versioning guidelines. In short, [bi] changes require a major version bump, feature changes require a minor version bump, and all others may fall under a patch bump (though discretion is advised - bumping a higher version level is always acceptable).

Versions are indicated in vM.m.p format, where M denotes the major version, m denotes the minor version, and p denotes the patch version, e.g. v1.0.6.

Versions are associated with the code using Git tags. This can be done via Git's tag command when viewing the correct change. Be sure to push the tag to the remote repository after creation, e.g.:

$ git tag v1.0.6
$ git push origin v1.0.6

Branches

Each major version should have its own branch. This allows updates to the software even after new major versions come out, in case older APIs are still used by some projects. Branch names follow the convention v#.*.* where # indicates the major version number.

All backwards-incompatible changes must be checked in to a different branch with incremented major version.

All bug fixes should be scrutinized to ensure that they are being applied correctly across all branches. This may mean the bug fix needs to be implemented differently in each major version.

Additional features should be applied to the most recent branch, and optionally to older branches (if feasible without major rework).