Contributing

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

Release policy

GumTree 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 releases is:

• Acacia (v1.0.0)
• Baobab (v2.0.0)
• Cedar (v2.1.0)

We will also try to associate a working jar to each release.

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

Branch policy

Master branch

• The master branch is supposed to be always working and contains all gumtree releases.
• Specific releases are associated to tags. Tags are named using semantic versioning.
• Bugfixes are directly committed 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.

Code policy

GumTree has strict coding style policies. There are enforced using checkstyle. To check if you code is compliant, use the command gradle check.

Preparing a new release

First, it is required to update the version number in the pom of all modules, using the following commands. The version used to the release should not have a trailing -SNAPSHOT. The version has to be edited in the root build.gradle file.

git checkout master
git merge develop
gradle build -Pmvn
gradle uploadArchives -Pmvn

Once the artifacts are released, checkout the develop branch and set a new version number, that ends with -SNAPSHOT in the root build.gradle file.

Auto-release

To deploy automatically on GitHub release, just merge develop on the master branch and create a tag. Then push to the origin repository, and Travis will take care of deploying.

git checkout master
git merge develop
git tag vX.Y.Z -m "vX.Y.Z"
git push --tags