Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
For scientific publications, ideally a permanently archived version of code should be available, for a couple of reasons:
How can I make a permanently archived version of an open source code available?
We're doing that with libpng. Every time we release a tarball, we make two copies (a current copy and an archive copy) on the libpng ftp/http site (libpng.download/src):
libpng16/libpng-1.6.32.tar.xz
archive/libpng16/xz/libpng-1.6.32.tar.xz
Then when we make a new release (e.g., 1.6.33), we remove libpng16/libpng-1.6.32.tar.xz and then repeat the above, creating
libpng16/libpng-1.6.33.tar.xz
archive/xz/libpng16/libpng-1.6.33.tar.xz
After this operation, the archive directory contains
archive/xz/libpng16/libpng-1.6.32.tar.xz
archive/xz/libpng16/libpng-1.6.33.tar.xz
and all previous versions back to libpng-1.6.0.tar.xz
There are other branches (libpng00, libpng10, libpng12, libpng14, libpng15, and libpng17) that contain the complete 22-year history of libpng releases.
When we release a "beta" tarball, the process is similar, except that a copy goes into the "beta" subdirectory:
beta/libpng16/libpng-1.6.33beta01.tar.xz
archive/xz/libpng16/libpng-1.6.33beta01.tar.xz
If you prefer another format, you can use "7z", "zip", or "gz" in place of "xz".
If you prefer to get your source out of the "git" repository, that's taken care of by "tagging" every release, so you can extract any particular release by means of its tag.
If you don't trust us to maintain the historical copies, you can always download the particular version you want to save and archive it on your own host or web site. Since libpng is open source, nothing prevents you from doing that.
Your best option is to clone the VCS repository. This will download every version of the source that has ever been published in that repository and save it on your local machine. Then keep your local copy with any other archived files accompanying your publication (you might want to tarball the local copy to keep it contained, and make sure that you include any hidden directories used by the VCS when you copy or archive it).
To keep track of which version to use when referring to the code, take a note of the relevant commit identifier. VCS systems have a way to identify a specific commit (git uses a commit hash, some other systems might use timestamps or sequential indexes). Later you can restore this specific commit from your local repository and you'll have a copy of the code exactly as it was at the point in time when that commit was made.
TL;DR Clone the repository and take note of the commit corresponding to the version of the code that you want to refer back to later. For a git repository (including GitHub), use git clone <repository URL> to clone the repository and git checkout <commit hash> to restore your local copy to a specific commit (the files in your local copy will change to match the chosen commit but git will keep every version in the hidden .git directory). For other version control systems, the commands and terminology will differ so consult the documentation and make sure that you're downloading the actual repository, not just a snapshot.
This is good practice. I know of two ways of doing it that also have the benefit of giving your archived code a digital object identifier (doi).
The hardest part of your question is IMHO not archiving but archiving permanently. Any service alone will not be able to provides this guarantee for the long term. Therefore to increase the likelihood your code will be avialable almost permanently, I would suggest using multiple places simultaneously to have multiple independent mirrors such as a combo of GitHub, BitBucket and Sourceforge as well as Figshare and Zenodo (that you mentioned in your asnwer) where each would contain a copy of the code (and possibly the corresponding publication) and cross-reference each other.
