Contributing

We welcome new contributers to Diggit. The process we use is the following:

Release policy

Diggit is released regularly. The versions number follow the semantic versioning scheme. Each release is associated to a tag in the master branch. Major releases are associated to a name. The current list of major releases is:

• Anchovy (v1.x.x)
• Beardfish (v2.x.x)

Since we do not currently have enough manpower to maintain multiple stable releases, whenever a new major release is handed-out, the maintenance stop on the previous release.

Branch policy

Master branch

• The master branch is supposed to be always working and contains all diggit releases.
• Specific releases are associated to tags. Tags are named using semantic versioning.
• Bugfixes are directly commited to the master branch.

Develop branch

• Development takes place on the develop branch.
• New features are developed in dedicated branches. These branches are then pull-requested into develop and peer-reviewed before integration.

Coding policy

Diggit policies can be checked using the command rake. In fact we even recommend to put this command in a pre-commit hook.

Style

Diggit has strict coding style policies. There are enforced using rubocop. To check if you code is compliant, use the command rubocop (to install it: gem install rubocop).

Testing

All code is tested using rspec (to install it: gem install rspec).

Preparing a new release

First the version has to be updated in lib/dgit/version.rb. Then the gem has to be built: gem build diggit.gemspec. Finally, the gem is pushed to rubygems: gem push diggit-x.x.x.gemspec.