TANGO is an object-oriented distributed control system. In TANGO all objects are representations of devices, which can be on the same computer or distributed over a network. Communication between devices can be synchronous, asynchronous or event driven.
The object model in TANGO supports methods, attributes and properties. TANGO provides an API which hides all the details of network access and provides object browsing, discovery, and security features.
For more information please visit www.tango-controls.org.
This repository is the result of svn2git migration of Tango source code previously hosted on tango-cs Sourceforge project. It is combined from api/cppapi, api/log4tango, api/cpp_test_suite anf api/cpp_test_ds
cppTango tango-9-lts branch is the branch dedicated to Tango 9 Long Term Support version.
On readthedocs: tango-controls.readthedocs.io
API reference: tango-controls.github.io/cppTango-docs
Old Manuals: tango-controls.org/documentation/kernel
See INSTALL file.
- In its most basic form, we adopt the githubflow : the default branch is master, which is always in a deployable state (i.e. must never be broken); work on new features is done using temporary feature branches (which may live in the same repo or in a fork)
- Reporting issues: use github issues
- Code contributions: use Pull requests. Pull requests can be associated with issues. Trivial fixes can even be done from the web (a temporary branch is created automatically to use the Pull request infrastructure)
- Code review: most projects (all except single-developer ones) should only allow commits to the master branch after peer review. This can be enforced by the convention that all commits to master must be done via a Pull request and the pull request approved by a person different from the author of the commit.
- Releases (named versions):
-
Simple projects may be ok with just tagging certain (ideally, all) commits done to the master branch with a version number. With this system, only one release is actively maintained simultaneously.
-
More complex projects may require to simultaneously maintain more than one release (e.g. Tango may choose to support bugfixes in Tango9 even after Tango10 is released). In this case, releases may be done on release branches starting from master (see APPENDIX I for an example)
- Semantic versioning is recommended.
- Public automatic testing/continuous integration (e.g., via Travis) is recommended
- The main development should be done on the tango-controls hosted project (as opposed to using a private organization project and just pushing to the tango-controls repo from time to time). This allows for public visibility of the latest development and issues and encourages sharing and reuse. If a given organization needs special tweaks or has particular release/testing cycles, the recommendation is that the organization forks from the "canonical" repo