Managing Software As Data » History » Version 18
Version 17 (Steve Welburn, 2013-01-08 12:17 PM) → Version 18/19 (Steve Welburn, 2013-01-08 12:35 PM)
h1. Managing Software As Data
For existing software used in research, the appropriate citation, version and source should be documented. This may need to include versions of any libraries required by the software as changes to the libraries may affect the outputs.
For new software, as for data, the management issues are:
* [[Backing_up|backing up]]
* [[Documenting_data|documentation]]
However, whereas data changes slowly / infrequently, software is subject to ongoing changes during a project. Source code for software usually consists of text files and should therefore be stored in a suitable version control system (e.g. "Mercurial":http://mercurial.selenic.com/, "Subversion":http://subversion.apache.org/, "git":http://git-scm.com/). Binary releases of software may also be created as downloads for a project.
Additionally, software documentation has broader requirements - including both documentation to make the code maintainable (e.g. comments in the code, documenting APIs, Javadoc style documentation) and user documentation to explain how to install and use the software.
The "Sound Software":http://www.soundsoftware.ac.uk project provides software project management facilities for digital music and audio research including Mercurial version control, downloads, documentation, issue lists and wikis through its "code repository":http://code.soundsoftware.ac.uk
Other possible repositories for source code include:
* "Sourceforge":http://sourceforge.net/ (Subversion, git, Mercurial, Bazaar, CVS)
* "Google code":http://code.google.com/ (Subversion, git, Mercurial)
* "github":https://github.com/ (git)
* "bitbucket":https://bitbucket.org/ (git, Mercurial)
The Sound Software project information on "choosing a version control system":http://soundsoftware.ac.uk/version-control-what-system-to-use and provides a "cross-platform, easy-to-use, graphical client":http://easyhg.org/ for use with Mercurial.
For existing software used in research, the appropriate citation, version and source should be documented. This may need to include versions of any libraries required by the software as changes to the libraries may affect the outputs.
For new software, as for data, the management issues are:
* [[Backing_up|backing up]]
* [[Documenting_data|documentation]]
However, whereas data changes slowly / infrequently, software is subject to ongoing changes during a project. Source code for software usually consists of text files and should therefore be stored in a suitable version control system (e.g. "Mercurial":http://mercurial.selenic.com/, "Subversion":http://subversion.apache.org/, "git":http://git-scm.com/). Binary releases of software may also be created as downloads for a project.
Additionally, software documentation has broader requirements - including both documentation to make the code maintainable (e.g. comments in the code, documenting APIs, Javadoc style documentation) and user documentation to explain how to install and use the software.
The "Sound Software":http://www.soundsoftware.ac.uk project provides software project management facilities for digital music and audio research including Mercurial version control, downloads, documentation, issue lists and wikis through its "code repository":http://code.soundsoftware.ac.uk
Other possible repositories for source code include:
* "Sourceforge":http://sourceforge.net/ (Subversion, git, Mercurial, Bazaar, CVS)
* "Google code":http://code.google.com/ (Subversion, git, Mercurial)
* "github":https://github.com/ (git)
* "bitbucket":https://bitbucket.org/ (git, Mercurial)
The Sound Software project information on "choosing a version control system":http://soundsoftware.ac.uk/version-control-what-system-to-use and provides a "cross-platform, easy-to-use, graphical client":http://easyhg.org/ for use with Mercurial.