Please open an issue.
The more detailed your report, the faster it can be resolved. Once the bug has been resolved, the person responsible will tag the issue as needs confirmation and assign the issue back to you. Once you have tested and confirmed that the issue is resolved, close the issue. If you are not a member of the project, you will be asked for confirmation and we will close it.
If you would like to contribute code to fix a bug, add a new feature, or otherwise improve sparkle, pull requests are most welcome. It's a good idea to submit an issue to discuss the change before plowing into writing code. The main criteria for acceptance are:
- a patch should be a minimal and accurate answer to exactly one identified and agreed problem,
- a patch that modifies a stable public API should not break existing applications unless there is overriding consensus on the value of doing this.
- A patch must adhere to the code style guidelines of the project.
Please include a changelog entry and full Haddock documentation updates with your pull request.
Every time a pull request is updated, the Wercker service runs continuous integration checks inside a Docker build container. A declarative specification of the build image is here. By design, the build image is not rebuilt at every new code push, because there is no way to use Docker registries as a cache for the result of building the Dockerfile to avoiding rebuilding the image all the time. This is because registries don't record what the build inputs for an image were.
If you change the Dockerfile or any of its dependencies, you should
publish a new version of the image. It will be used as
the environment for subsequent CI checks.