Can adoupdate avoid updates that are too new to run?

[Richard Williams]

I was asked this question but don't know the answer.

Suppose I am running an old version of Stata, e.g. Stata 16. I run adoupdate. But, one of the updated programs now requires Stata 17 and won't run under my version of Stata.

Is there any easy way to avoid this, or do I just have to check programs individually before I update them?

When I update my own programs that I put on SSC, I try to avoid making changes that require me to change the version unless some new Stata feature is critical for the program.

[daniel klein]

No, not that I know of.

The adoupdate source code is open and nothing in there indicates such functionality. One could think about reading the required information from the

d Requires: Stata version #.#

line in the respective pkg-files provided one such line exists and is up-to-date, i.e., contains the most recent Stata version required. Others have to judge whether it's worth the effort.

[Nick Cox]

daniel klein is capturing my thoughts too.

adoupdate doesn't offer this functionality.

If you want StataCorp to provide it, that would be a feature request.

The chance that everything would work as you would like is moderately limited. Extending Daniel's comments.

1. I imagine that the code would need to look inside your ados for version information.

2. If that doesn't exist, or can't be found. you need to spell out what you want the update to do.

3. Version information can be misleading. Sometimes program authors give the version of Stata they are currently using on the grounds that their code evidently works in that version and they have no grounds for asserting that it would work in an earlier version. Other authors give older version numbers on various grounds. Either can be wrong for a downloader. Suppose you are on Stata 16 but someone posts a command declaring version 18. You may be able to edit that to 16 as your risk to see if the program works in 16. On the other hand, presumably you could still use adoupdate and take your chances with the code once you've downloaded.

4. Evidently the trade-off is delicate. An upgrade costs money for you or your workplace. Some long-term users compromise by upgrading every other version, or only when they are missing out on something really valuable to them. The most active community developers tend to use the latest version, so the cost of upgrading is often missing out on new functionality from users as well as from StataCorp.

[Richard Williams]

Thanks. This is what I suspected.

I have every version of Stata from 7 on still installed on my computer. Whether they all still work, I'm not sure. Old help files can be handy sometimes for understanding what is now antiquated syntax (but which still works under version control). Also, if I do tweak a program, I can check if it still runs on older versions of Stata. Once I did make some tweak that zapped the program, but it was easy enough to rewrite the code so it again worked ok.

Sometimes, after rewriting a program, authors rename the old version and make it available on SSC, e.g. I have oglm9 on SSC for anyone who is condemned to still using Stata 9, which hopefully isn't many.

Roger Newson goes to heroic efforts to keep old versions of his programs around:

https://www.rogernewsonresources.org.uk/stata.htm

I don't know of anyone else who is as dedicated as he is.

[Richard Williams]

It would be nice if adoupdate could avoid doing updates that won't work. But, StataCorp probably has little incentive to increase the likelihood that Stata 13 will continue running with no problems.

[Nick Cox]

I run with the hares and hunt with the hounds here. Automation is great but at some points users have not the only the right but also the obligation to think hard about what they want. Downloading something you can't use is not a great burden, but it may be annoying or frustrating..

[Chen Samulsion]

Professor Williams. I'm also much concerned about the question you raised. More often than not I don't like to upgrade community-contributed command just because I am afraid that the upgraded command will not run in older version of Stata. And this often result to silly mistake and waste of time. Just as in my recent thread, you told me that

You are probably making this much harder than it needs to be (but if so, several others have made the same mistake).

I think there are at least three versions of brant around.

And I found that some people have good habit of retaining copies of old command in their own website, for example your gologit2 and gologit29, and Professor J. Scott Long in Indiana University, and Roger Newson in Queen Mary University of London. Really hope this will be widely spread, although I know it's very hard.

Sometimes, after rewriting a program, authors rename the old version and make it available on SSC, e.g. I have oglm9 on SSC for anyone who is condemned to still using Stata 9, which hopefully isn't many.

Roger Newson goes to heroic efforts to keep old versions of his programs around

[Nick Cox]

The world of Stata community-contributed programs here splits into three, as follows.

1. Stata Journal It's been a principle since early days (Stata Technical Bulletin 1991) that updates appear in new directories, so you can always revert.

2. SSC. The onus is here on programmers. SSC won't keep two or more versions of foo.ado or foo.sthlp. When a revision breaks earlier code or requires a different version of Stata, the principle I try to follow is that the older code remains available, if only under a different name. Such attitudes seem common.

3. Everywhere else. People using GitHub can underline that much of the point is to keep old files accessible. People using other sites can, or should, follow #2 or something equivalent.

[daniel klein]

But, StataCorp probably has little incentive to increase the likelihood that Stata 13 will continue running with no problems.

Well, there's also a tradeoff, too. Time StataCorp. spend keeping older community-contributed software running (beyond providing their exceptional version control) means less time developing new tools and functionality.

[Nick Cox]

#9 daniel klein I don't read this thread as including any idea that StataCorp should give more support to community-contributed software, but only that some people want some extra functionality to tell people what community-contributed software they can't use. That would be a one-off addition to the update code, but I can't speak for precisely how difficult that would be or how much effort it would require.

[Chen Samulsion]

Not direct relevant to Williams' question, but still worth to pay attention. require package wrote by Sergio Correia and Matthew P. Seay https://arxiv.org/pdf/2309.11058