Stata programming: The lowest version of Stata on which the routine will run.

[Min Zhang]

Dear Statalist,

I am working on my first Stata program package and would like to share it on SSC. I have a small/silly question related to Stata version.

According to SSC instruction, "Every ado-file in the SSC Archive must have a Stata version n.n command to indicate the lowest version of Stata on which the routine will run."

The question is that I do not know the lowest version of Stata that supports my package.

My simple program package involves only recoding and labelling. I checked Stata 8 manual and found that recoding and labelling in Stata 8 is not much different from Stata 13, which I use to write the package. (I am aware that there are some difference in recoding between Stata 8 and Stata 13. But the difference is not relevant to my package.)

Recoding and labelling seems (not sure yet) compatible to Stata 8. But how about Stata programming language? Does Stata programming language evolve over time?

The lowest Stata I can find is Stata 12.

Many thank,
Min

[Richard Williams]

I think usually people just specify whatever version of Stata they wrote it on. If you want to specify an earlier version you can try to test it with an earlier version. I have every version of Stata from 7 on so if I change one of my programs I can test it on whatever version of Stata is on the version command.

[Roger Newson]

A possibility is to test your programs under version control. As in:

version 10: mypackage

which will attempt to run mypackage.ado as if under Version 10, if your Stata is version 10 or higher. This is probably the best way that exists of testing a Stata package under old versions, if you do not have the old versions installed.

I personally follow a policy of writing my Stata packages at the lowest feasible level, or at Version 10, whichever is higher. (I no longer write packages in Stata 9 or below, as then I would have to write .hlp help files instead of .sthlp help files, and that would cause problems with a lot of users' firewalls.) This is because I want my packages to be usable by as many users as possible. I have written a package dologx, downloadable from SSC, specifically for users who write certification scripts to test their packages and want to do so as if under earlier Stata versions. Bill Gould wrote an extremely useful article on certifying Stata packages in the first issue of The Stata Journal, and you can download this from

http://www.stata-journal.com/article...article=pr0001

I hope this helps. And congratulations on writing your first Stata package.

Best wishes

Roger

[Nick Cox]

There is a fuller discussion at https://www.stata.com/support/faqs/p...stata-version/ The question isn't the same, but most of the details apply here.

Running your command with a prefix like

version 10: 

does much less than you might guess and is, in my view, not the answer here.

For example, version 10 (or any other number less than 15 as I write) does only what is documented under the help for version, which is to revert to earlier behaviour in certain very limited respects.

Stata users say: version is not a time machine. Even under version: Stata will not ignore

1. bug fixes (good news)

2. completely new features added since the declared version and in your current Stata

3. user-written programs you may have installed and may be using in your program.

The only sure test is to find Stata for which the current version is version # and see if your program(s) run as intended. (Even then it's possible that a user needs to install user-written programs if they feature in your code.)

People with a version lower than yours may be interested in your program, download it, but then find that it does not work. Despite the changes documented in the help for version, the most likely reason here is that you have used features added since.#.

People with a version lower than yours may be interested in your program, download it, but then find that as their version is less than # it will not even run. It's possible that an edit would make the program work.

[Richard Williams]

Just to add to what Nick says, you can (at your own risk) try lowering the version number in a program. But you have to make sure it is giving the correct results.

One thing I like about Stata is that it is very to keep old versions around. Just don't uninstall old versions or, if moving to a new computer, just copy the folder they were installed in, For example, for Stata 7 my shortcut target is set as

"C:\Program Files (x86)\Stata7\wstata.exe"

and it starts in

"C:\Program Files (x86)\Stata7"

I control my computer so I can do this. But others may be at the mercy of system administrators so this may not be an option for them. And, of course, they may not have purchased old versions in the first place,

Another advantage of keeping old versions is that, in effect, much of Stata is undocumented. A command may use version 5 of Stata, but you don't have the help file for Stata 5 so you can't look it it up. If you have old versions, you can open the old versions and check the help files.

[Min Zhang]

Dear Statalists,

Many thanks for your kind replies. I found them very helpful.

I decided to state:

version 10

One of the reasons is related to help file. @Roger Newson mentioned his preference for sthlp file over hlp file. I remember @Nick Cox also said something similar in an old post regarding his personal policy (I could not find it). I also checked the paper @Roger Newson suggested and installed his package dologx (although I am not sure if it does what I intend).

@Richard Williams and @Nick Cox suggested that the best way is to test with old Stata. The program went well with Stata 12, which is the oldest version I had. I will try to borrow Stata 10 from a colleague. I checked Stata10 documents and believe that the program should work with Stata10.

Many thanks again for your suggestions.