Stan 1.0.0 release this week?

[Bob Carpenter]

We're pretty much ready to release Stan 1.0.0. [*]

Jiqiang: what's the readiness status of RStan
1.0.0? And is there anything I can do to help?

Everyone: should we coordinate the releases?

I'm guessing if we make a "Stan's ready" announcement,
lots of people will try whatever version of RStan is
out there.

[*] I'm polishing off the rest of the doc and there's
a minor outstanding bug in transforms that Marcus may
have already patched.

- Bob

[Marcus Brubaker]

On Mon, Aug 27, 2012 at 3:54 PM, Bob Carpenter <ca...@alias-i.com> wrote:
> We're pretty much ready to release Stan 1.0.0. [*]
>
> Jiqiang: what's the readiness status of RStan
> 1.0.0? And is there anything I can do to help?
>
> Everyone: should we coordinate the releases?

Definitely, unless RStan is weeks off from 1.0.

> I'm guessing if we make a "Stan's ready" announcement,
> lots of people will try whatever version of RStan is
> out there.
>
> [*] I'm polishing off the rest of the doc and there's
> a minor outstanding bug in transforms that Marcus may
> have already patched.

I have a patch for it but it's mixed in with my overall changes to add
a positive_ordered type. I can separate it out if you'd prefer that
those changes didn't land right now (or at all).

Cheers,
Marcus

[Jiqiang Guo]

It is good to go this week.  I am working the dots now.  

I do not think I have some big issues to work on.  

I might need some help with the doc inside rstan if we are very serious about say

writing and grammar. 

--

Jiqiang

On Mon, Aug 27, 2012 at 3:54 PM, Bob Carpenter <ca...@alias-i.com> wrote:

[Ben Goodrich]

On Monday, August 27, 2012 3:54:54 PM UTC-4, Bob Carpenter wrote:

Everyone: should we coordinate the releases?

I would say that every Stan release should imply a new rstan release, although it may occasionally be necessary to release a new rstan without releasing a new Stan (due to CRAN policy changes, changes in packages rstan depends on, bugs in R code, etc.)

Ben

[Jiqiang Guo]

And we would try to put rstan on CRAN after stan is released.  It might take more time for the first version of rstan as we might need tailor it to CRAN's policy. 

--

Jiqiang

--
 
 

[Bob Carpenter]

We definitely need to fix the bug in the ordered type.
If it's too hard to tease that out, I can just patch
it directly.

If you can test it and doc it, then add it. If not,
wait.

As Marcus suggested, though, I think we eventually
want to just add constraints to the ordered type
rather than a separate positive-ordered type.

- Bob

[Bob Carpenter]

On 8/27/12 4:20 PM, Jiqiang Guo wrote:
> It is good to go this week. I am working the dots now.
> I do not think I have some big issues to work on.

Awesome! This is very exciting.

> I might need some help with the doc inside rstan if we are very serious about say
> writing and grammar.

I'm happy to proofread it for English.

And I'll throw in a look at the content
for free :-)

- Bob

[Marcus Brubaker]

Ok, I've pushed the bug fix and the positive_ordered type. It
includes unit tests, source level docs and a note in the language
section of the docs.

When/If we add bound constraints to the basic ordered type
positive_ordered can become a synonym or removed depending on how
widely it gets used.

Cheers,
Marcus

> --
>
>

[Bob Carpenter]

I'm very psyched to hear that we'll be in synch to start,
so the comments I added below are forward looking.

I would like to stick to a

major.minor.patch

release numbering scheme, with any change in
documented functionality implying at least a
minor version update.

I only care that Stan/RStan numberings synch
so that any RStan major.minor version will run
any major/minor-matching Stan version.

So I wouldn't have minded releasing Stan 1.0.0
when we're only up to RStan 1.0.beta.

The problem I see with Stan getting ahead of RStan
on minor version number is people reading the wrong
doc. The install of RStan is encapsulated, so that
shouldn't cause a problem.

- Bob

[Bob Carpenter]

On 8/27/12 5:09 PM, Jiqiang Guo wrote:
> And we would try to put rstan on CRAN after stan is released.

Yes, that'd be great.

Hopefully, when RStan distribution moves to CRAN, all
we should have to do is update the installation doc on
the R Getting Started page.

> It might take more time for the first version of rstan as
> we might need tailor it to CRAN's policy.

Do you think that might affect functionality? Can we
anticipate how at this point?

- Bob

[Bob Carpenter]

On 8/27/12 5:50 PM, Marcus Brubaker wrote:
> Ok, I've pushed the bug fix and the positive_ordered type. It
> includes unit tests, source level docs and a note in the language
> section of the docs.

That's great.

> When/If we add bound constraints to the basic ordered type
> positive_ordered can become a synonym or removed depending on how
> widely it gets used.

I'm for making it a synonym later.

I'd rather not break backward compatibility for
models unless we absolutely have to.

And then, I'd rather break backward compatibiltiy in
two stages, first by deprecating the old behavior in
the current major version, then updating to a major
version that removed deprecated functions. That gives
users a clear upgrade path with warnings in their code
to help guide their fixes.

- Bob

[Ben Goodrich]

On Monday, August 27, 2012 6:05:34 PM UTC-4, Bob Carpenter wrote:

> It might take more time for the first version of rstan as
> we might need tailor it to CRAN's policy.

 

Has anyone attempted to build a rstan binary for Windows on the CRAN server yet?

http://win-builder.r-project.org/

My guess is that if that works, then the Mac binary will also build successfully but that is not guaranteed.

Ben

[Jiqiang Guo]

I was just thinking about something about CRAN's policy I do not know. 

What we can anticipate is the boost I am included, which is about 2M in the package, but 20M after unzipped. 

I am inclined to put it there and try first.  If we do not include, if CRAN can build rstan, the user need to specify the boost.lib using parameter boost_lib during calling stan.  If CRAN cannot build rstan, then it will be a trouble for users to get started with rstan. 

--

Jiqiang

[Bob Carpenter]

On 8/27/12 7:22 PM, Jiqiang Guo wrote:
> I was just thinking about something about CRAN's policy I do not know.
>
> What we can anticipate is the boost I am included, which is about 2M in the package, but 20M after unzipped.
> I am inclined to put it there and try first.

I think it'll be much easier that way.

Maybe Andrew can lobby the CRAN maintainers
for special dispensation. They seem to make
decisions on a case-by-case basis and there
don't seem to be hard limits on sizes.

> If we do not include, if CRAN can build rstan, the user need to specify
> the boost.lib using parameter boost_lib during calling stan. If CRAN cannot build rstan, then it will be a trouble for
> users to get started with rstan.

Right, and I think that'll be a problem for
a lot of users.

I would try to do the same with Eigen. It'll
be easier for us to manage that way than through
Rcpp because we can guarantee versions. (But as
we've discussed before, we can live with RcppEigen
if necessary.)

- Bob