eventstudy2 package(the neweast version) conflict with Stata17?

[Emilio Chen]

The case is linked with two versions of `eventstudy2` package.

- The older version on my machine(that is `v2.0.1`): eventstudy2.ado eventstudy2.sthlp
- The newest version since `v3.2b`: (It could be download by `ssc install eventstudy2`)

With the following test code in the `help eventstudy2`:

earnings_surprises.dta

test.do

```
use Earnings_surprises.dta

// test 1
eventstudy2 Security_id Date using Security_returns if Earnings_surprise > 0.05, returns(Return)
```

In stata 17, it works with the v2 version, but complained the following with version 3.2b: `< invalid name`

I don't have lincense for Stata18 or Stata19, but with `ssc install eventstudy2`, it would download the newest version of `v3.2b`. What cause this breaking change in this case? Is there any workaround to make `eventstudy2` has much better compatibility for Stata17 and below? Thank!

[Thomas Kaspereit]

Dear Emilio,

Thank you for using eventstudy2. I can confirm that the updated version works correctly with test1 on Stata 19.

Unfortunately, I am unable to test compatibility with older versions, as I do not have a license for them.

You have already kindly posted an older version of eventstudy2.ado, so users can revert to that version if they do not have a license for Stata 19.

Best regards,
Thomas Kaspereit

[Emilio Chen]

Dear Emilio,

Thank you for using eventstudy2. I can confirm that the updated version works correctly with test1 on Stata 19.

Unfortunately, I am unable to test compatibility with older versions, as I do not have a license for them.

You have already kindly posted an older version of eventstudy2.ado, so users can revert to that version if they do not have a license for Stata 19.

Best regards,
Thomas Kaspereit

Well thanks to your reply! Do you know what breaking change from stata17 to stata19 that cause this? Is the lateset `everything2` package always just maintained with the latest stata version(but not the older version's compatibility)?

Best wishes!
Emilio

[Thomas Kaspereit]

Dear Emilio,

I have not yet fully understood what changed between Stata 18 and Stata 19 with respect to the syntax command. The syntax command is used to define the structure of user-written commands (.ado files).

Before Stata 19, options such as CAR1UB in the syntax command of eventstudy2.ado were translated into the user-facing option car1UB and into an internal local macro of the same format (`car1UB'). Since Stata 19, however, these options appear to be translated to car1ub on the user side and to an internal local macro named `car1ub'.

I assume that this new behavior is more logical, which is likely why the Stata developers implemented the change. Still, such a modification of fundamental syntax behavior is quite rare.

eventstudy2.ado is a mature command and largely free of bugs. I can say this with confidence because, for almost three years now, I have not received any major requests for debugging, while download statistics indicate that the command continues to be used. Therefore, you are unlikely to miss any important updates if you continue using v2.0.1 that you kindly uploaded above.

To answer your question directly: yes, if an update were ever required, I would implement it using the Stata version available to me at that time, and not the older versions.

Best regards,
Thomas Kaspereit

[Nick Cox]

One way to make progress here is to

set trace on 

and see exactly where the error occurs within the code.

Depending on exactly how complicated the code is (especially whether the main program calls other programs, and so on) you may need to tune the trace depth with a number, e.g.

set tracedepth 1

or a larger number. The delicate balance is between too much and too little detail.

[Alan Riley (StataCorp)]

Dear Emilio,

I have not yet fully understood what changed between Stata 18 and Stata 19 with respect to the syntax command. The syntax command is used to define the structure of user-written commands (.ado files).

Before Stata 19, options such as CAR1UB in the syntax command of eventstudy2.ado were translated into the user-facing option car1UB and into an internal local macro of the same format (`car1UB'). Since Stata 19, however, these options appear to be translated to car1ub on the user side and to an internal local macro named `car1ub'.

I assume that this new behavior is more logical, which is likely why the Stata developers implemented the change. Still, such a modification of fundamental syntax behavior is quite rare.

eventstudy2.ado is a mature command and largely free of bugs. I can say this with confidence because, for almost three years now, I have not received any major requests for debugging, while download statistics indicate that the command continues to be used. Therefore, you are unlikely to miss any important updates if you continue using v2.0.1 that you kindly uploaded above.

To answer your question directly: yes, if an update were ever required, I would implement it using the Stata version available to me at that time, and not the older versions.

Thomas, first, thank you for already providing an update that resolves this in eventstudy2. This happened due to a change made to the parsing of options by the syntax command in the 24sep2025 update. Quoting from item 4 of the whatsnew:

"4. Command syntax now supports numbers in minimum option abbreviations, identified by capital letters at the beginning of option names. You can now define an option name that includes a number between capital letters and this will not produce an error message. For instance, previously, using option name, say, CASE1OPtion with syntax in a program would produce error message "option case1option not allowed", when option case1option was specified with the program. This is allowed now, and the desired minimum abbreviation case1op works as expected. However, if a number appears at the end of the minimum abbreviation, such as CASE1option, the number will continue being ignored in the minimum abbreviation, such as case instead of case1, per the original design of syntax."

When this change was made, it was considered that the previous behavior was a bug, and our testing at the time could not find any cases where it affected any official command or anything in our certification. Obviously it affected eventstudy2, however. We will need to consider whether we should make any additional changes to this, but my initial feeling is that the old behavior was indeed a bug/limitation which prevented behavior that should have been expected from syntax. Additionally, the old behavior of sometimes leaving capital letters in the local macro goes against what syntax was supposed to do when parsing options. I welcome any feedback on this.

[Emilio Chen]

Thomas, first, thank you for already providing an update that resolves this in eventstudy2. This happened due to a change made to the parsing of options by the syntax command in the 24sep2025 update. Quoting from item 4 of the whatsnew:

"4. Command syntax now supports numbers in minimum option abbreviations, identified by capital letters at the beginning of option names. You can now define an option name that includes a number between capital letters and this will not produce an error message. For instance, previously, using option name, say, CASE1OPtion with syntax in a program would produce error message "option case1option not allowed", when option case1option was specified with the program. This is allowed now, and the desired minimum abbreviation case1op works as expected. However, if a number appears at the end of the minimum abbreviation, such as CASE1option, the number will continue being ignored in the minimum abbreviation, such as case instead of case1, per the original design of syntax."

When this change was made, it was considered that the previous behavior was a bug, and our testing at the time could not find any cases where it affected any official command or anything in our certification. Obviously it affected eventstudy2, however. We will need to consider whether we should make any additional changes to this, but my initial feeling is that the old behavior was indeed a bug/limitation which prevented behavior that should have been expected from syntax. Additionally, the old behavior of sometimes leaving capital letters in the local macro goes against what syntax was supposed to do when parsing options. I welcome any feedback on this.

Thanks to your paraphase, but the breaking change, IMHO, is always need second consideration, NOT all the users would always use the latest version, but `ssc install` would always install the newest one, which make it much easier to encounter with version mismatch.And not all the developer are active on the forum, that may cause many related issues.

[Nick Cox]

Everyone has a point here, if of different weights. StataCorp surely have a responsibility as well as a right to fix bugs and limitations. Those writing community-contributed commands usually and defensibly write for themselves in the first instance: the altruism consists (usually) of making code freely available to others. You get what you didn't pay for!

Speaking only for myself as a poster of some community-contributed code I try to be mindful of those using older versions of Stata and wouldn't want to revise a command and make it inaccessible to those using previous versions. But sometimes it happens.

A resolution may lie in making available versions of the command that will work on older versions of Stata. As far as SSC is concerned that would mean using a different command name.

Most of my own commands change only through small fixes and extras but catplot on SSC is a example of a command with one original version in 2003 and two major rewrites since then, yet all the files are there under different names.

[Alan Riley (StataCorp)]

One thing to note is that eventstudy2 could be modified to check to see if it is running under a version less than 19 or not, and it could then handle both cases immediately after parsing, putting the contents of what syntax produces into a common set of local macros which then could be used unchanged throughout the rest of the code. This would allow it to work both under Stata 19 and earlier versions. We often make changes like this in official ado-files. It is one of the great advantages of having the ability to branch based on version.