Skip to content
Emerson Murphy-Hill edited this page Jul 17, 2017 · 22 revisions

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)

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

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.

Clone this wiki locally