Skip to content

Home

Jump to bottom
Apostolos Samaras edited this page Jun 12, 2018 · 10 revisions

Development and Releases workflow

Our Git workflow is based on the Trunk/Cactus workflow. We have, obviously, considered other workflows including the infamous A successful Git branching model, however with a highly dynamic team of contributors of various levels of experience, GitFlow was not the easiest thing to introduce.

Development

QLACK team members

This is for long-term contributors, being members of the QLACK Development team on GitHub.

If you want to use any QLACK module for development, you simply clone the master branch of the respective repo. Since master is the default branch name in Git (unless you specify otherwise) there is nothing special here other than e.g. git clone https://github.com/eurodyn/Qlack2.git.

Third-party contributions

You may fork the repo you want to contribute and issue Pull Requests against the master branch. A team member will promptly review your PR and either merge it or suggest additional changes.

Patches & Hotfixes

To create a patch or a hotfix for a previous version:

  1. Checkout the tag you need to base your hotfix on.
  2. Create a new branch named after the version number of your hotfix. For example, if the current version is 2.1.2 and you need to create a hotfix on 2.1.0, you should name your branch as 2.1.0.1.
  3. Perform your changes, build and make sure all tests pass.
  4. Commit your changes to 2.1.0.1.
  5. Push 2.1.0.1 branch.
  6. Git tag 2.1.0.1 and push your tag.

Release process

We release regularly and automatically publish all our releases on Maven Central. From the time of building and publishing a release expect at least a couple of hours before it becomes available/searchable in Maven Central.

Publishing to Maven Central is incorporated into our build process via a release profile, so there is not much you should manually execute. However, to be able to publish you need some extra, one-off setup (contact the team on #qlack channel for assistance):

  1. During publishing you will automatically create tags and push those tags. So, you should be able to access GitHub via SSH keys, so you need to have your public key uploaded on GitHub, see connecting-to-github-with-ssh.
  2. All release artifacts are GPG-signed. You need to have the private-key as well as the password to use it.
  3. Configure your settings.xml to contain an entry for the GPG password:
<server>
  <id>gpg.passphrase.qlack</id>
  <passphrase>FOOBAR</passphrase>
</server>
  1. Request the access token for the Sonatype server we are using as an intermediary for publishing to Maven Central.
  2. Configure your settings.xml to contain an entry for the Sonatype server we are using as an intermediary for publishing to Maven Central:
<server>
  <id>ossrh</id>
  <username>FOO</username>
  <password>BAR</password>
</server>
  1. Request PGP keys.

Once the above conditions are met you are ready to publish QLACK to Maven Central:

  1. Make sure you have all latest sources. If necessary, commit, merge, and push changes.
  2. mvn release:clean release:prepare -Prelease
  3. mvn release:perform -Prelease

Rollback a release

To rollback a release, in case something went wrong during your maven build, you may issue: mvn release:rollback -Prelease.

In addition to the above you should also:

  1. Delete the newly created tag for the unsuccessful release on GitHub.
  2. Delete the newly created tag for the unsuccessful release on your local repo.
  3. If your local versions did not fully revert, you can manually set the old version back with
  • mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT
  • mvn versions:commit
Clone this wiki locally