Home

Development Protocol

• We use semantic versioning to set the versions of the tool.
  • Most of the changes/fixes will be released as patches.
  • When new features are implemented, a new minor version will be released.
  • Major versions will be released only if the changes are too deep and/or it breaks API compatibility
  • The release of a new major/minor version will include the update of the RELEASE.md file describing the main changes
  • The current version will be specified in VERSION.md file.
• master branch keeps the last released version of the the queries/webserver and web-client respectively.
• Future versions are named with a trailing x for the patch part of the version. For instance, 0.4.x branch will include all the patches for 0.4 release.
• dev branch includes extra things that are out of the scope of any branch.
• Tags of the project keep track of previous versions.

Sending an Issue

• Create a new issue and describe the problem/comment
• If you are going to address the issue, create a new branch and call it following the pattern: "issue/NUMBER", where NUMBER is the number of the issue.
• Implement the changes to address the fix/improvement in the new branch.
• Send a pull request over master branch. Call the pull request following the pattern: "Addressing #NUMBER", where NUMBER is the number of the issue addressed.

Reviewing a Pull Request

• If you are the release manager, you have to review the Pull Requests.
• Check carefully the code included in the branch.
• If required, create the WAR and deploy in the server.
• If everything works fine:
  • Comment on the Pull Request the result of the deployment
  • If required, advance the version and update VERSION.md. If minor/major versions are modified, update the RELEASE.md. Commit/push changes to Pull Request.
  • Merge the code.
  • Accept/Close the Pull Request.
  • (Optional) Remove the branch.