Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
- 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.mdfile describing the main changes
- The current version will be specified in
masterbranch keeps the last released version of the the queries/webserver and web-client respectively.
- Future versions are named with a trailing
xfor the patch part of the version. For instance,
0.4.xbranch will include all the patches for
devbranch 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.
Clone this wiki locally
Press h to open a hovercard with more details.