Setting proper version for ado files

[Niels Henrik Bruun]

Hi
How do You find out which version is needed when developing an appilcation to Stata.
Is there a tool that can loop down all used commands in the code and gives a minimum version number?
Or what can I do to set the proper version in my code?

[Nick Cox]

Although its question is not yours, http://www.stata.com/support/faqs/pr...stata-version/ includes much of what can be said. Do come back with questions if any remain, but I don't know of a program that will read your programs and tell you the minimum version on which they will work. That is tricky, because it would need to be based on an inventory of user-written programs and what they need, and it would need to know about the details of syntax (e.g. some regress calls would work in version 1.0 and some require much, much later versions, say because they use factor variable notation).

As an off-putting one-sentence start: setting (e.g.)

version 11

is sufficient to make your program fail on any previous version, but will typically have almost no magic effects otherwise.

The FAQ cited was my attempt (with help from others) to be as clear and to give as full a statement on versioning your programs as is possible, however.

[Niels Henrik Bruun]

Hi Nick
Thank you for your answer and the link.
I haven't tested this, but what if I set trace on, ran an example from my code and looked for all lines starting with "- version".
Wouldn't that give a good picture on how low I can go with respect to setting the version?

[Nick Cox]

Depends. Let's backtrack: the way this kind of question may arise is that you have written a program and now you need to know whether it will work on another machine with a lower version of Stata. Let's say the other Stata is version 11. Then finding version 12 or version 13 anywhere in your code trace would seem to rule that out. But there could still be exceptions. Perhaps the other Stata has, or could get, an earlier version of the same thing. Or perhaps there is a version-dependent branch in the code and your Stata took that branch because it could. This is common in official code.

In essence, this is all a consequence of StataCorp maximising the extent to which earlier code can run. It creates fuzzy zones and the ultimate answer is often that you have to try it!

[Niels Henrik Bruun]

I understand.
But still that must be the best I can do, right?

[daniel klein]

I understand.
But still that must be the best I can do, right?

Theoretically this should work, but it sounds time consuming and I would really think twice whether it is worth the effort. I would go for the earliest release available to me, test the program, then declare that version.

As you posted another question about documenting Mata code today, I suspect you have used Mata, so the minimum version of Stata required is 9 (as this is when Mata was introduced). Chances are, there are not too many people/companies out there, still on version 8 or earlier.

Best
Daniel

[Nick Cox]

I have lost sight of what you are intending to do precisely, either what you discussed or what I suggest. My best short answer is that scrutinising a program that works on your own machine with your own Stata can be time-consuming and is rarely completely decisive. The best test of whether a program works with a particular version is to try it with that version and to test whether it runs and also gives the desired results.

Let me answer further but obliquely. I have put a lot of programs in the public domain and now rarely, if fact almost never, test that a program will work on machines with the declared version. Beyond depending on some knowledge of Stata, that may seem cavalier if not irresponsible. Well, that's true. But in essence it's a way in which publicly shared programs are tested and improved, just as I never publish a program with a claim that it's bug-free, but trust that people who care will let me know about bugs, as they often do. If a program won't work on the version stated I hope to be told so, and then we can work out what to do (which may be nothing, as the problem is insoluble in practice). The alternative of slapping version 13.1 on every program I write would have more disadvantages to any body of users interested. But as the FAQ outlines, that's personal style and other user-programmers jump the other way.

[Niels Henrik Bruun]

Hi
Thank you both very much.
I think I've got my answer.
I was curious about a functionality which can be quite important for potential users of code and off course distributors.
I can easily live with Nicks way of handling it, but then I would also find the concept rather obsolete.

Again thank you both.
Have a nice weekend

[Richard Williams]

I have every version of Stata from 7 on installed on my computer. Luckily, it is pretty easy just to copy the files from one computer to the next, i.e. I don't have to actually go through the install routines. Mostly I keep them around for the help files. But, if i want to make sure that one of my programs runs in an earlier version of Stata, then I run it in an earlier version of Stata. A lot of times I will make some change that requires Stata 13, and it is not that hard to tweak the code so it runs in 11.

[Niels Henrik Bruun]

Hi Richard
Regretably that is not an option for me.
I've published one application to Stata (ssc) and I intend to make more, so that is the reason for me asking.
At my first I did as I described above, and that is probably what I'll continue doing, maybe combined with a lower version level like version 11.
Then I go back to July 2009, which seems fair to me.
Also this way I take Mata into account as well. And I will use Mata for most of my future code.

Anyway thank you very much for your comment