[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
Alan Riley <ariley@stata.com> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: adoupdate question |

Date |
Mon, 29 Jun 2009 20:40:52 -0500 |

Richard Williams (Richard.A.Williams.5@ND.edu) asked about -adoupdate- and ado-files downloaded from SSC for Stata 11 vs. Stata 10: On Mon, Jun 29, 2009 at 04:06:25PM -0400, Richard Williams wrote: > I wonder if -adoupdate- becomes potentially dangerous for people who > don't update their Stata version. Suppose you have Stata 10, and you > have a routine you downloaded from SSC that works with Stata > 10. Then, the author updates the program so it requires Stata > 11. When you run -adoupdate-, won't the version that works with > Stata 10 get overwritten by the version that requires Stata 11? > > Most authors will probably keep a renamed version of the earlier > program available, but it might be nice if adoupdate warned you when > you were about to update to a program you can't run. It is true that -adoupdate- will seek out the newest update to a given package which has been -net install-ed, no matter what the version number is in the ado-files in that package. So, Richard is right to be thinking about this. It would be possible to modify -adoupdate- to take note of a version comment within the text of the package file it is checking, but even better than that would be for this to be a feature understood by Stata's -net- command. It is too late for such a feature to be added to Stata 11, but we may add it in the future. However, Richard's email leads me to want to talk about version control in user-written programs. Over the years, I have seen authors of user-written programs put out a command named, say, 'x', which runs under Stata 11, and put out another command, say, 'x_10', which is known to run under an earlier version of Stata. End-users must decide whether to install 'x.ado' or 'x_10.ado' and must remember to type -x- or -x_10-. There is a simple, and better, solution, for authors of user-written programs who wish to implement version control in the way developers at StataCorp would do so. This solution lets users of Stata 11 type -x- to access the Stata 11 version of x.ado, and it also lets users of Stata 10 type -x- (NOT -x_10-) to access the Stata 10 version. The author of the program still creates x.ado and x_10.ado, but x.ado has a few lines of code in it which allow it to be smart so it can call the older x_10.ado if a user is running under version 10: ----x.ado-------------------------------------- program x if _caller() < 11 { x_10 `0' exit } version 11 // the code for the Stata 11 version // of 'x' goes here end ----x.ado-------------------------------------- ----x_10.ado----------------------------------- program x_10 version 10 // the code for the Stata 10 version // of 'x' goes here end ----x_10.ado----------------------------------- This takes no more work for an author who was going to create both x.ado and x_10.ado anyway, but it is cleaner for end-users. It also means that even if a user installs an updated version of the 'x' package, as long as they have used version control in their own do- and ado-files, the appropriate version of -x- will be executed. --Alan (ariley@stata.com) * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**RE: st: adoupdate question***From:*Richard Williams <Richard.A.Williams.5@ND.edu>

**RE: st: adoupdate question***From:*"Nick Cox" <n.j.cox@durham.ac.uk>

**Re: st: adoupdate question***From:*Richard Williams <Richard.A.Williams.5@ND.edu>

**References**:**st: adoupdate question***From:*Richard Williams <Richard.A.Williams.5@ND.edu>

- Prev by Date:
**st: Adjusted R square & cluster** - Next by Date:
**Re: st: Analyzing a subpopulation in Stata 10.1** - Previous by thread:
**st: adoupdate question** - Next by thread:
**Re: st: adoupdate question** - Index(es):

© Copyright 1996–2017 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |