Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: further version questions

From   Stas Kolenikov <>
Subject   Re: st: further version questions
Date   Wed, 29 Sep 2004 08:38:52 -0400

> But that would gain you nothing, really. -mvis- is just part
> of a package and the whole package would need
> to be scanned in a bid to remove Stata 8 features,
> which would I guess require considerable programming
> expertise. 

Can I pick from here on my own thing? Each time I update Sophia
Rabe-Heskteh's -gllamm-, some of the modules come out to be outdated,
which I only find out when it crashes. (I know -net install- should
work perfectly, but I found once that one of the older pieces was
sitting in a directory of -adopath- prior to others, and thus caused
problems until I deleted it from there). So for all five or six
ado-files I have to type -which gllamm-, -which gllapred-, etc., and
compare to the current versions on -gllamm- website.

So my suggestion/wish/grumble to Stata Corp. is to set up something
like -userversion- version control system, so that the internal
version of the module is specified not through

*! v.3.1 NJC 29 September 2004

in the first line of the ado-file, but as a 

*! NJC 29 September 2004
program define blahblah, eclass
   version 8.2
   userversion 3.1
   userneed blahblah_ll 1.11

Then whenever -blahblah- calls -blahblah_ll-, the -userversion- of the
latter is checked against 1.11 and should be no less than that. Or an
option like

   userneed blahblah_ll 1.11, strict

can be provided for the lazy programmers like me who do not want to
program their routines to be backward compatible, so that the current
version of -blahblah- will only accept -userversion 1.11- to work

Is this too much to ask for? Does anybody else in the stataworld need
this except me?

Stas Kolenikov
*   For searches and help try:

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