Just a reminder that we’re doing quarterly releases and the next one is October 18th. I brought up at the Stan meeting today the idea of having a feature freeze for the week before the release and everyone agreed. So I’ll ask folks contributing to CmdStan, Stan, and Math repos to not merge any PRs that aren’t (small) bugfixes during that week. This is motivated by the 2.20 release which had some heroic last minute efforts to get fast compile times in but also broke GPU and MPI and we found out <24h later.
Let’s have the feature freeze starting midnight Friday October 11th, which is a week before the release date of October 18th. This means I’m asking folks with merge permissions on CmdStan, Stan, and Math to hold off on merging any new features (or other large changes) to develop so we can focus on finding and fixing bugs on develop for the week leading up to the release. This may prove to be too long or too short a window but let’s give it a shot and we can tweak it going forwards. I think for this release it’s particularly important as we have some major changes coming down the pike such as adding the TBB (which involved a lot of makefile changes) and switching CmdStan to stanc3.
The math devs at the last meeting talked about it. Our working assumption was that we’d keep working and merging and tag one git hash dated 10/11 or prior as the release git hash.
But now I see how that could be problematic in the global release; that would trickle down different git hashes since a change to a submodule is just a code change.
Happy to spread the word. Is there some permissions we can set so this is handled automatically?
Yeah, in an ideal world we could make a release branch (rather than a tag, so that we can update it with bugfixes). That would require some changes to the release scripts which would I suspect wouldn’t go right on the first try, haha. It would also require discipline around everyone involved knowing where to send PRs for which bugfixes (and making sure we didn’t accidentally send them to develop first, etc) and then a final merge of the release branch back into master and develop. I think this has more moving parts and requires more centralized coordination so my preference would be to try to go with just a feature freeze on develop for now. It shouldn’t really affect folks so much with a distributed version control like git - should be roughly equivalent for whoever is antsy to make a new branch that everyone can merge into. That way the same level of coordination required is not on the critical path to release, haha.
That’s a neat idea - The only thing is we can’t distinguish between feature and bug PRs with github. So it would probably amount to locking it down entirely and lifting the lock manually each time or something like that…
Do you want to switch RStan? I think the main things that I don’t know where they stand are
Returning error messages when the Stan program is invalid
Dealing with #include statements. Since the Javascript thing is sandboxed from accessing the filesystem, I guess we’ll have to handle this with the C preprocessor before calling stanc. But in that case, it would be better if the language allowed quotation marks around the path to the included file (actually I suspect stanc has not worked in the past for paths with spaces or other weird characters in them because quotation marks are illegal).
Dealing with rstan::expose_stan_functions. This currently calls a different version of stanc that does not generate a class but does put double-only functions into the global namespace that call the user-defined functions in the model namespace.
Having the same arguments as regular stanc. In particular, it would be good if there was a flag that could be passed to return the AST instead of the C++ code.
Thanks for the notice – I still need to expose the newton solver. I can brute-force do it through stan, and then we can hopefully get it reviewed. That said, I want to this in stanc3, for which I’ve had some issues.
Also, when do we require all the documentation to be written? Does it have to be before the feature freeze?
It would be good to have the same stan->C++ transpiler on all interfaces if possible.
As if Jenkins anticipated the freeze, but at least for today the Jenkins Windows systems are not processing anything. I hope the last bits and pieces of the TBB can shortly be merged… from my view all problems are solved.
@charlesm93 Getting the Newton solver in sounds very ambitious. It seems to me that you would have to get potentially even into stanc3 and in to stan unless all interfaces refrain from using the stan transpiler. Otherwise it would depend on the transpiler used if the Newton solver works or not. I would probably concentrate on stanc3.
My proposal for this would be that we try to switch RStan to stanc3 when RStan is ready for 2.21 in maybe 3 months or so (estimated given RStan 2.20 isn’t out yet). That will give us time to iron out bugs with the smaller group of more low-level CmdStan users before foisting the new compiler on the entire RStan community. And it will give me some time to implement the Javascript API as you’ve described it - I’m now convinced that approach will work, but I just need to spend some time building that adapter layer. Everything you say here should work, I’d guess I (or anyone else who is interested!) just need to sit down for a few days and work on it.
Re: JS long term: as we add optimization passes that get increasingly complex, JS may become less and less of an ideal solution here as it runs something like 100x slower than the native code so far. We could even have both a builtin JS file that is CRAN-friendly as well as an install_stanc() option to download a native binary for performance once it is ready.
Woops, didn’t see this before. I was trying out Breck’s favorite “Midnight Anywhere on Earth” (which is apparently a real thing: Anywhere on Earth – AoE Time Zone). So that’s in about 6 hours but I don’t recommend staying up - there will be another release January at the latest.
As a reminder, please don’t merge any new features to develop in the next week starting in about 6 hours. After the week is over we can do a little retrospective on whether that was too long or too short a time period, etc.
I didnt need to stay up late as that time is morning in Europe :)
There were a few approved PRs that were only waiting for Jenkins to finish last night. I went through those on Math/Cmdstan (there were none on Stan) this morning and merged. As of right now, there are no more approved PRs so it will be a clean deadline.
For Math there is nothing left. The static init PR has issues with passing tests on Jenkins, other than that its good to go. I dont think static is critical for 2.21 though.
We’ve released! How do folks think the feature freeze went? Was it too long or too short? Let’s have a nice discussion about it here (or not if everyone thinks 1 week of feature freeze in exactly that way was perfect, haha).
Mostly good! Still saw the anxiety buildup from folks that wanted stuff in this release right near the end. Maybe not announcing the exact day would be better (or worse, idk!)
I think it was good. Pulling off stanc3 did. hurt, but this was the kind of stuff we wanted to do. The makefile also saw some improvements wrt to the tbb which are good to have in the release.