Bluntly, this depends -- partly -- on how far one cares
about making one's programs available to others.
Richard has himself put stuff on SSC, so he does
care. I also put stuff on SSC, so I care, although
in practice life is sometimes too busy to accommodate
all possible users.
A Stata programmer writing a program afresh
is likely now to be developing it with the 8.2 executable
and 8.2 ados and as such to declare -version 8.2-.
StataCorp work hard at enhancing the language and
developers make life easier for themselves by
exploiting new features to the full. Naturally
anyone wanting to build on the new graphics or the new
-ml- (say) has essentially no choice here. Conversely
there are tasks that do not require newer features.
Even then many programmers find the newest features
-- even such more or less cosmetic details as // or /// --
pleasant to work with, which blows compatibility even
with Stata 7.
Another common situation, however, is that a new
program can be written as a minor variation on
an existing program, which may well be declared
as Stata 6 or Stata 7. Rewriting that to Stata 8.2
may well be unnecessary: the best advice may well
be "if it's broke, don't fix it". Thus often users
add some small tweak to an official command and
write -<command>2-, say. If -<command>- is a few
dozen lines long and full of oldstyle stuff (say
macro shifting rather than -forval- or -foreach-
loops) it may be satisfying to rewrite it afresh.
If it is a few hundred lines long, it is usually
better to fix only what needs fixing (and even experienced
programmers may well be wary of rewriting a long
command: not only will it take time, breaking
something by accident is a real risk).
Yet another fairly common situation is that
a Stata programmer is updating a program to
Stata 8. One possible policy is to leave (say)
-foobar- written for version 7 in place in an
archive such as SSC as -foobar7-
and to declare that frozen henceforth. This
is a gesture to those still on Stata 7. (The gesture
includes the advice to upgrade Stata!) Meanwhile
-foobar- will now be the version for Stata 8.
There are thus at least two conventions. A widely
held convention is to imply that -<command>2-,
-<command>3, etc. are successive (unofficial) improvements
on -<command>-. A less widely used convention
is that -<command>6- or -<command>7- mark
_historic_ versions requiring at most Stata 6
or Stata 7. The existence of these two conventions
-- and I believe I am to blame for introducing the
second -- is possibly a little confusing, but in
practice most improved variants have numbers no
bigger than 2, and I don't think anyone is now concerned
with paying much consideration to compatibility
with any version lower than 7, unless it is costless.
Nick
[email protected]
Richard Williams
> I have a question about version numbers in ado files: you
> are supposed to
> include the version # the ado file was developed with,
> right? e.g. if I
> wrote an ado file today, I should include a line that says -version
> 8.2-. That guarantees it will keep working ok with later versions.
>
> But suppose that the ado file would have also worked fine
> with version 7,
> version 6, or whatever. Have I kept it from working with
> earlier versions
> because I included the line -version 8.2-?
>
> I just tried changing an ado file that said -version 6- to
> -version 9-, and
> sure enough, it said that it wouldn't work, and I would
> have to upgrade my
> version of Stata.
>
> Would it be considered good practice to try lower version
> numbers on your
> ado files, until they stopped working correctly?
>
> The version command is nice in that it keeps old programs
> working, but it
> looks like it may make you pay a price for not buying the
> latest and
> greatest version of Stata!
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
