Accessing older versions of SSC modules

[Brian Quistorff]

Is there any way to access an archive of historical versions of modules at the SSC? I'm thinking of the case where someone is trying to reproduce analysis and newer versions of dependencies behave differently. I've tried the Internet Wayback Machine but that doesn't appear to work (e.g. the history of the /g/ directory just shows errors).

If there isn't currently a way, such a tool would seem like a great addition to furthering the reproducibility of Stata research projects. It would seem quite feasible to setup a machine to periodically download (every month?) the SSC packages to a version controlled filesystem that has a web front-end. The traffic would be minimal.

[Richard Williams]

Sometimes old versions are rereleased with new names, e.g. gologit29 is the old version of gologit2. Roger Newson is really good about keeping old versions of his programs around: http://www.imperial.ac.uk/nhli/r.newson/stata.htm. Programs published in the Stata Journal will often have both older and newer versions of the program available. If you are really desperate, I suppose you could write to the author and see if they have an old version sitting around.

[Nick Cox]

Richard gives good advice. SSC works in the simplest possible way. If authors send new versions of existing files to Kit Baum, they just overwrite the previous versions. There is no archive of the archive so far as I know, and I've been sending stuff to it for a while.

In principle, this is an interesting point. In practice, I don't think I've ever seen it mentioned before in the joint history of SSC and Statalist, so it doesn't seem to bite often.

[Richard Williams]

I wonder how often a user-written program gives different results across time. If it does it may be because the program had a bug originally (or has one now). The syntax options may change, but if so you can hopefully figure out what the syntax is now. Or you may need to run Stata under version control, as Stata itself doesn't always yield the same results (e.g. there have been changes in the sorting routines across time).

Stata is pretty good about having programs work with version control, e.g. old syntax will work if you use version control. But I suspect few, if any, user written routines provide such support. Rather than try to support version control, I think many authors just rerelease an old version of their program under a new name.

[Robert Picard]

I think a good strategy to deal with the issue of replicability and user-written programs is to simply integrate them (with attribution of course) in your project. For example, you can create an "ado" subdirectory at the base of your project directory and include in the master do-file (assuming that Stata's current directory is the one that contains the master do-file)

adopath ++ "`c(pwd)'/ado"

to let Stata know that programs are also located there and that they have priority over other versions installed elsewhere.

The ssc command does not offer an option to specify where user-written programs are to be installed. However, assuming that Stata's current directory is set to the "ado" subdirectory, you can type

net set ado "."

and subsequent ssc commands will install all files in your local "ado" project directory.

To check for updates, you type

adoupdate, dir(".") update

To uninstall user-written programs

ado uninstall prog_name, from(".")

More and more journals are requiring that data and code be made available as a condition for publication and naturally, these journals are also employing people to check that the submitted code replicates the results reported in the paper. So at a minimum, the submitted code should a) run and b) generate the results found in the paper.

With respect to a), making user-written programs part of the project will make your code run without additional steps and will also future proof your code should a user-written program be removed or changed. Also, if you only use relative path names for files, your code will not have to be changed in order to make it run on a different computer. Each do-file should start with a version command that indicates which version of Stata was used to create the code. Such do-file will not run on an older version of Stata and should run fine even if a newer version of Stata is used instead. As others have pointed out, Stata reserves the right to change its behavior in newer versions so there is no guarantee of replication unless the same version that created the code is used to run it (so keep your old versions of Stata when installing a newer version).

For anyone concerned with how to make code portable and replicable, I strongly recommend project, from SSC. It is the only tool available at this time for Stata that can check every single thing produced by a project for replication (dataset, log files, tables, figures, etc.).