[wbuchanan]

I can strike my previous ask regarding levelsof. One thing that could be helpful/useful - particularly for user contributed code - would be some form of dependency management. For example, in this post a user ran into an error working with a user-written program that was caused by a dependency not being installed on the user's system. While the dependency was clearly documented being able to add something to a .pkg file to install any/all needed dependencies could be useful/helpful as well. With the Java API I could see this as a way to potentially avoid some headaches that might be caused if one or more programs depend on the same and/or different versions of Java binaries.

[Carole J. Wilson]

I second that request! In the past, I've occasionally used a system where the program asks users to install Erick Booth's usepackage (SSC) and then issue calls to it within the program to check for and install missing programs.

[wbuchanan]

Carole J. Wilson I've done something similar here, but it could also be helpful for user-programmers to avoid creating multiple forks of a single project by specifying a specific version of the program. It becomes even more problematic on the Java side where multiple instances of the same classes on the classpath can cause issues. Since I started doing a bit more with Java, I've come to like tools like Maven (you use a configuration file called pom.xml to specify specific libraries, versions of the libraries, and/or whether or not those binaries need to be compiled with your program or should be found on the users' system.

[Lucas Higuera]

I'd love the expansion of the me capabilities to choice models (clogit, asclogit, mlogit, etc.), and a vce option that computes Krinsky-Robb standard errors. Now the Bayesian capabilities in Stata should make my wishes not too hard to implement.

[Clyde Schechter]

I would find it helpful if -margins- had a -saving()- option that placed the calculated margins and the associated at() values (or values from the -margins- varlist) in a Stata data set. The reason for this is that sometimes I like to graph the results in ways that are difficult or not possible with -marginsplot-. Yes, I can always do -margins, post- and tinker with that to create a data set, but that's inconvenient. Saving the results directly into a data set would expedite things.

[Ariel Karlinsky]

This is a great thread with some outstanding requests/issues. I also have a few but I wonder if anyone from StataCorp even looks at this thread. I second the motion to create a "user sugesstions" forum where we could also get some feedback from StataCorp regarding issues/sugeestions and what StataCorp is currently working on - including bugs. take for example this bug I reported: http://www.statalist.org/forums/foru...-calculate-bug

StataCorp did reply that it is indeed a bug and that they're working on it but if some user was to have the same issue he might not find my thread and the StataCorp comment on it, report the bug again, or think that there's something wrong with his code. Just like with each stata update whatsnew includes the fixes and additions to stata (e.g. "xtprobit & xtlogit failed to estimate robust SEs with time series variables - this has been fixed"), it should also have this sort of list regarding bugs that are "in the works" (e.g. "xtprobit & xtlogit fail to estimate robust SEs with time series variables - fix expected in may 2016")

[wbuchanan]

I can't imagine the in work/progress status would be posted since it might force StataCorp to commit themselves to development (or a timeline) that ends up not being accurate. I'd imagine that one of the major challenges would be regression testing (in the software not statistical sense) issues. Maintaining backwards compatibility the way Stata does requires significant effort and introducing new features can sometimes break existing source code (this is what regression tests are used for) and finding a solution that doesn't cause a regression can sometimes take a while. That said, I think your major idea to known/reported bugs along with potential solutions for them would definitely be valuable to the wider community. It could be a read only set of threads where the issues get posted by StataCorp staff and then are removed or marked as closed when a solution is added to a release.

[daniel klein]

I would find it helpful if -margins- had a -saving()- option that placed the calculated margins and the associated at() values (or values from the -margins- varlist) in a Stata data set.

That wish was already granted. margins has a saving() option since day one (i.e. Stata release 11) but it has not been documented.

Best
Daniel

[Clyde Schechter]

Dan,

Thanks for telling me that. I never knew about it. This'll be a great time saver for me.

[Nick Cox]

I can't speak for StataCorp but I can make a few general comments based mostly on the history of past releases (including marginal involvement, as when a few of my commands were added to past releases) and comments by developers at users' meetings and Stata conferences.

The company works on a cycle with a major release every two years, so we expect Stata 15 in 2017.

Writing the software is in practice coupled with writing the documentation (help and manual), writing test scripts, writing dialogs and testing the code with a variety of executables on a variety of platforms. It's more or less as if every developer at Stata were permanently in the last two years of writing a thesis for a doctorate or writing a substantial book. (If you've been there, or not, the summary is very busy indeed with a mass of small and large problems.)

I'd guess wildly that most of what will be in Stata 15 is already pencilled in in broad terms.

So, why are StataCorp so coy about what is forthcoming? I suspect that there are three major reasons.

3. StataCorp do have other commercial competitors. It's not a good idea to tell your competitors about your product plans until you launch.

2. StataCorp don't know for certain what's in a release until it ships. Even very big projects can be pulled at the very last moment because the view is that it is just not good enough or big problems emerge, e.g. a command keeps crashing on a class of test cases. Long term, you wouldn't want them to work differently. (Shucks, I waited ten years for a new rename command.) Or, somebody was working on something and then they left the company, or had time out, or whatever.

1. Mostly, it is to treat users fairly. The way this could bite otherwise is various. But suppose you base your personal or group budgeting on buying Stata 15 or your research timetable similarly, because StataCorp say, Oh, we're going to implement zombie analysis, which is what you really, really need to raise your project from the dead (I hope that's not a known technique anywhere). And then come Stata 15, but there is no zombie analysis. The zombie stuff didn't pan out well. This usually is at least very embarrassing and it takes little imagination to imagine serious user upset: your plans are really messed up. In short, the company doesn't want to make any promises it can't be sure of keeping. It does tell you that a bug will be fixed if it's clear that there is a solution which can be implemented any way.

On top of all that, it should need no emphasis that this is a public forum!

[paulvonhippel]

I wish the -reshape- were faster, and inspection of the code suggests that it could be implemented in a much faster way. For details, please see:
http://www.statalist.org/forums/foru...reshape-faster

[paulvonhippel]

See especially this post which highlights an opportunity to make -reshape- faster:
http://www.statalist.org/forums/foru...67#post1338567

[Dirk Enzmann]

I am hesitating adding a wish to this wishlist because by making it longer it is becoming muddy and confusingly complex. And I am considering the title "Wishlist for Stata 15" being unfortunate -- better would be "Wishlist for Stata 14.1+" because we never know when its wishes will come true (why not with Stata 14.2?).

However, because I am still very uneasy with the fact that Stata's commands are still able to produce unintended side-effects (which, of course, should be avoided by any means) I am stubbornly reiterating my wish

• that either Stata would check to see if there are any variables with temporary names and then avoid using those names as it creates new ones, even if the current data set is newly opened
• or that Stata would per default drop temporary variables when saving a data set and would -- instead of the current practice of saving temporary variables automatically -- have the option "keeptemp" added to the save command to save temporary variables if the user really wants this.

For those not familiar with the problem that could be solved by either of these changes / additions see http://www.statalist.org/forums/foru.../general/84940 . I know that this post is utterly complex and hard to understand immediately. Thus I am considering writing a Stata Tip for the Statajournal to make people (and StataCorp) alert of this issue.

[wbuchanan]

Dirk Enzmann I've definitely been bit by the saving temp variables bug myself, but don't necessarily see it the same way that you do. For example, after the script or .ado completed, the temp variable would be dropped from memory, but writing the data to disk should include the variable as well. That said, I think an option like you're suggesting would be helpful/useful.

[Nick Cox]

Many, perhaps most, commands you run entail creating temporary variables without you even knowing it. For example, egen fires up a variable that records the order of observations so that it can be restored once egen is done. Although the existence of temporary variables can have occasional side-effects as mentioned, I suspect that this request isn't consistent with how Stata is written.