Home
Welcome to the graph-dsl wiki! graph-dsl is a quick and easy way to create graphs and perform algorithms on them. It creates a traditional set of vertices and edges and provides a lot of groovy magic to deal with them.
#Status ##Master
##Develop
#Continuous Integration
graph-dsl uses travis-ci to build, test, and run static code analysis for sonarqube.
This process is not in place yet but it should include automatic publishing from master to maven central.
This project uses gitflow-avh with github pull requests. For these to work together some rules should be followed.
- Pull requests are used to run checks and allow comments. Sonar adds comments for issues it finds.
- If a pull request resolves and issue it should have (resolve #X) to close the issue in github when it is merged.
- For features pull requests should be made against develop.
- For releases and hotfixes pull requests should be made against master.
- Releases should be made for each feature merged. There should only be bug fixes release branch.
- Documentation should be updated to reflect the new release.
- Internal pull requests should not be merged through github.com. Instead, use gitflow to do the merge. Once gitflow merges the branches, github.com should be automatically marked as merged by github.com.
I'm not sure how to handle external pull requests yet.
git flow feature start <name>
git push --set-upstream origin <name>
git flow feature finish <name>
bugfix branches are exactly like feature branches except they address a bug.
git flow bugfix start <name>
git push --set-upstream origin <name>
git flow bugfix finish <name> -k
Features and bug fixes should be released as soon as they are merged to develop. This is so they can be continuously delivered and to make semantic versioning much easier.
git flow release start <semantic version>
Pick <semantic version> according to semantic versioning. Bugs should increment the 3rd digit. If a feature make breaking changes increment the major version if not increment the minor version.
This creates a release branch from develop. The version number is automatically "bumped" by the gradle git flow plugin: apply plugin: 'com.github.amkay.gitflow' an example of what the version is
Inferred version 0.2.0-pre.7+sha.22c2439
The version on the release branch is a pre-release. Once git flow release finish is called it becomes a real release.
Once a release branch is created it should be pushed to github.
git push --set-upstream origin release/0.2.0
This will create the branch on github and push it.
Now a pull request should be created between the release branch and master. This is to review all of the changes before they are finally put into master. It also allows any issues filed to automatically be closed.
Perform all actions needed to complete the release. There should be very little coding since the feature should already work. Fixing minor bugs is ok though.
It is important to remember to update the README.md file with release information. Also ensure any changes to the usage section are made.
Once the release is ready complete it. Use -k to make sure the release branch can be pushed which merges the pull request.
git flow release finish <semantic version> -k
Make sure all branches and tags are pushed to github.
git push --all
git push --tags
This should result in the pull request being merged and a release being added to github. Delete the release branch.
git flow release delete <semantic version> -r
Edit the release in github updating it with release notes. If it is a pre-release mark it in github.
The normal gitflow workflow breaks pull requests in github. Here is the workaround.
//use the -k flag to keep the feature branch
git flow feature finish test -k
//after all the merging is done, the PR should be marked as 'merged', so you can delete the remote branch
git flow feature delete test -r