Bugfix release, hotfix for TMD5-caused crash on ifarm

Fix for TMD5-caused crash on ifarm (#50)

* Fix for TMD5-caused crash on ifarm

Bugfix release, deploy all outputs

Not all outputs were deployed due to unsupported wildcards in travis.yml.

Bugfix release, deploy correct outputs

This bugfix release will correctly deploy the outputs to github release.

Bugfix release, fixes #44

This release re-enables the suppression of tracks when they hit a kryptonite volume. It speeds up the default simulation by quite a bit.

Bugfix release, fixes #38

Merge pull request #41 from JeffersonLab/hotfix_issue38_visualization

Hotfix issue38 visualization PR into master

Plane detectors, multi-threading support, patch release 1

Bug fix release that fixes the sign of the inelastic ep scattering to -0.8 x 10^-4 Q²/GeV².

Plane detectors, multi-threading support

With this release support for multi-threading support is introduced. To be able to take advantage of this, you will need a geant4 installation that has support enabled. If you have a regular non-multi-threading geant4 installation, this release will run in single thread mode, as before.

Due to changes in the pseudo-random number generators, this version will give a different sequence of events than v1.0.0, but there are no changes to the actual physics, input macro syntax, or output ROOT file structure.

Plane detectors, pre-CD0 benchmark version

With this release, I am hoping to introduce a remoll semantic versioning scheme and organized branching modelto help with more organized and benchmarked simulations. I'm not trying to make anyone's life more difficult; in fact, it's to the contrary!

Released versions will have a version number vX.Y.Z where:

• Major revision X is incremented whenever the macro API changes, i.e. changes in behavior of existing messenger commands or changes to existing fields in the output ROOT trees. With these changes, users should expect that their remoll macros and analysis macros may not work. Note that the addition of messenger commands and the addition of output variables is backwards compatible and does not require an update to the major revision number.
• Minor revision Y is incremented whenever there are substantial feature changes, such as a substantial change in geometry, addition of an event generator, etc.
• Patch revision Z is incremented whenever there is a bug fix that can't wait until the next release (e.g. event generator is throwing pions when you thought it was throwing electrons).

The released versions will have reasonable default settings to ensure reasonable running time. This means no optical photon simulations and no large shower simulations. The experimental configuration in released version will be set, by default, to the MOLLER default running mode: electron-electron scattering with detectors in parity-mode locations. A set of benchmark simulations will be automatically run on every released version. If you are merely interested in running simulations, not in developing them, you should only ever need a released version.

The branching model will change slightly to be closer to the model described in A successful Git branching model, and graphically summarized below:

This model will allow for keeping the master branch stable and reliable, while giving feature branches a path towards integration and release into the master branch. There's no expectation that you will read the document above, though it may help you understand the philosophy behind it. Some of the conventions in the model description (e.g. branch naming, fast-forward avoidance) are not at the core of what we are trying to achieve, so they will not be enforced.

The master branch will reflect the latest released version. Thus, a git clone of the repository will always give you a sensible starting point for simulations, and no breakage should typically be expected when doing a git pull (only exceptions are major revision changes). It speaks for itself that code in master must always compile and run without issues. Issues should be raised and bugs will be fixed promptly by creating hotfix branches (i.e. not by committing changes directly into master).

A new develop branch will reflect the most up-to-date integrated code from feature branches and continuous development. Periodically, feature branches will be merged back into develop, from where they will be merged into a release-vX.Y.Z branch, and finally into master. Code in develop should compile and run without issues, but stability of APIs is not always to be expected. It serves mainly as a mechanism for code integration.