I’m wondering if we might un-overload the “Stan 3” term. RStan 3 / PyStan 3 refers to the backwards-incompatible user-facing API refactor described in User Interface Guidelines for Developers. “Stan 3” refers to the backwards-(in)compatible language redesign. These two things have absolutely nothing to do with each other.
I think at one point there was an idea that both these refactors would go in at the same time. My sense is that this isn’t the case any more. (PyStan 3 is ready for an alpha release about now.)
I’m tempted to pull a “Windows 10” call the new user-facing API “PyStan 5” just so nobody gets confused. But if RStan doesn’t want to do this for “RStan 3” then this might create some confusion. Any thoughts? @bgoodri ?
I wouldn’t quite say that the Stan 3 “interface” refactor has nothing to do with the Stan 3 “language” refactor, although we did originally intend for them to happen at the same time in order to reduce the number of backward incompatible changes. The virtual class for models and the ability to query a concrete instance of a model are important for the interfaces.
More generally, I haven’t worked on rstan3 that much recently and even if it were ready, it would take a considerable amount of time to get all the rstanarm-like packages on CRAN converted to the new syntax. Ideally, we could have a 2.999999… release sometime that was compatible with both syntaxes.
Anyway, I don’t think it would hurt much if you released PyStan3 whenever but I don’t think rstan3 is particularly close to ready.
Ok, so we’ll go ahead and release “pystan 3” with the idea that
eventually RStan will make a release that uses the same/similar syntax.
That sound right?
What about the idea of jumping to PyStan 4 or RStan 4 just so there’s no
confusion with the “Stan 3” language?
I don’t think we can hold up the new interface release for a blockless Stan++ language. I do think we can
[optionally] synch up a Stan 3 language release that removes all the deprecated features (like _log probabilities and <- assignment and direct access to lp__).
This would help with maintaining the language by simplifying a lot of the code.
Whether or not we do this, we can
release RStan, PyStan and CmdStan 3 with the current language (Stan 3 if we deprecate, just plain old Stan otherwise)
Then we can release blockless Stan without breaking backwards compatibility and not have to renumber interfaces in the future.
Ok. I’ll go ahead and move towards a PyStan 3 “alpha” release for
sometime in 2018. I’m going to use 3.0 as the version number to signal
that the user-facing API is incompatible with the old API.