Accessing previous versions of the packages in SSC

[Roberto Berwa]

I was trying to reproduce the results of a paper from 5 years ago. The packages used from ssc are outdated. Thus, I cannot reproduce the results without going through a lot of pain. Is there version controlling in ssc? If not, do you think it is needed for the purpose of reproducing results? Or are there other ways to lock certain versions of the package in the production code of a paper?

[Sven-Kristjan Bormann]

There is no version controlling on the RePEc servers (where SSC is hosted) as far as I know, but I might be wrong. You would need to contact RePEc via email [email protected]
You could also contact the authors the paper you try to reproduce for their code. Or you contact the author of the package directly and ask for an older version.

I guess that it would be useful to lock the version of the packages used in a paper, in case the results change in a newer version. But probably authors of a paper should save their versions of the packages used. Unless the author of a package uses a version control system like Git, then it boils down to look whether older versions are available.

You could post the paper and the problematic packages here. Maybe it is possible to solve your problems here.

[Leonardo Guizzetti]

You might post a link to the paper in hopes that someone might be able to give specific advice about the code in question. If it's a matter of rounding error due to a simulation, say, then the the impact is quite negligible. But if it's a whole routine for something, that is quite another thing.

[Sergiy Radyakin]

Roberto Berwa , reproducing earlier results can be a pain even when you have access to the same packages.
See some advice here: https://github.com/BPLIM/Workshops/r...y_Radyakin.pdf
In your case, if the packages were updated, there is still a chance that the files are available somewhere. Still it is hard to say without specifics (which file, version are you looking for?).

[Nick Cox]

Those who use GitHub will be amused -- and possibly even appalled -- to know that SSC has no notion of preserving earlier versions, except insofar as authors unilaterally ask for earlier versions of commands to be preserved under different names. Thus recently I mentioned cpcorr

. ssc desc cpcorr

--------------------------------------------------------------------------------------------------------------
package cpcorr from http://fmwww.bc.edu/repec/bocode/c
--------------------------------------------------------------------------------------------------------------

TITLE
      'CPCORR': module for correlations for each row vs each column variable

DESCRIPTION/AUTHOR(S)
      
      cpcorr produces a matrix of correlations for rowvarlist versus
      colvarlist. cpspear does the same for Spearman correlations. This
      matrix may thus be oblong, and need not be square. Both also
      allow a single varlist.
      
      KW: correlate
      KW: matrix
      KW: oblong
      
      Requires: Stata version 10.0 (6.0 for cpcorr6, cpspear6)
      
      
      Author: Nicholas J. Cox, Durham University
      Support: email [email protected]
      
      Distribution-Date: 20150916
      

INSTALLATION FILES                               (type net install cpcorr)
      cpcorr.ado
      cpcorr.sthlp
      cpspear.ado
      cpspear.sthlp
      cpcorr6.ado
      cpcorr6.hlp
      cpspear6.ado
      cpspear6.hlp
--------------------------------------------------------------------------------------------------------------
(type ssc install cpcorr to install)

which was first posted in 2001 and revised in 2015. The 2001 version was written for Stata 6 and it cost almost nothing for me in 2015 to rename the original files so that any users of Stata 6 through 9 were not deprived of the code.

That said, I have posted often on SSC since 1997 when Kit Baum started it, IIRC, and have revised many packages, deliberately overwriting older versions many times, with the intent of

fixing bugs

adding features

improving code generally (e.g. rewriting ancient code, improving loops, rewriting key sections in Mata)

improving the help files

The SSC system, as said, does not allow versioning as such. In all of this, programmers' time and convenience is important too: I and many others provide software freely but without recognising indefinite obligation to support possible future needs of users to access older versions. Heck, people paid me nothing and probably didn't even cite me in their papers! I don't even preserve older copies for my own records except by accident.

If X can't reproduce the results of Y using code written by Z, it should be no great embarrassment to either X or Y if lack of reproducibility is down to a software change by Z.

In 23 years I don't recall a single request for a copy of an older version of my packages, so I don't feel embarrassed by this. personal policy.

Naturally, I have no idea whether the OP is referring to anything of mine. I am just speaking personally and not presuming that other SSC contributors agree.

There are other considerations too.

In trying to reproduce earlier results it is vital to recognise that the version of Stata you are using may have changed too in important respects. Stata has a strong idea of version control but it does not include allowing users to access earlier versions of commands that differed because of bugs...

The strongest version control in the Statasphere is that of the Stata Technical Bulletin and Stata Journal, whereby all versions of programs published through either remain accessible, even if they contained bugs.

Earlier replies contained good advice

* be specific about the problem

* contact the program authors

* contact the paper authors