# New v2.17.1 release for Math and Stan?

**URL:** <https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442>\
**Category:** Developers\
**Tags:** maintenance\
**Created:** [November 6, 2017, 6:29pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442 "2017-11-06T18:29:37Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 14, 2017, 9:54pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/61 "2017-11-14T21:54:37Z")

</div>

Sure. We also already merged a similar, but not the same, commit into `develop` (and this is where we differ from how people normally use that git flow). I would want to be very careful when trying to merge `master` back into `develop` and replaying similar commits with similar intentions on top of each other - I think you’re right that if git finds the line already matches what it was supposed to become then there won’t be a change and it will work out fine. Issues only crop up if other people have edited those lines in the meantime, and we’ve had a lot of files touched already on `develop` (like putting all tests under cpplint). So that’s why I think your route implies more work and caution. But you mentioned a reason why having a tag that isn’t merged into master doesn’t work well for RStan and I was hoping you could dive more into that - I would have imagined RStan 2.17.1 would point at Stan tag v2.17.1, no?

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 14, 2017, 10:01pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/62 "2017-11-14T22:01:59Z")

</div>

If you do

```
git checkout bugfix/revert_string
git merge -s recursive -Xtheirs --no-commit develop

```

there are no merge conflicts, although one test got broken. After fixing that test, there will be no conflicts if you merge `bugfix/revert_string` into `develop`. After doing that, there shouldn’t be any future problems merging `develop` into `master. A`git merge`doesn't replay all the intervening commits like subversion or`git rebase`, so it only matters what is in the tip of`develop`when it is merged into`master`. If, for whatever reason — which I can’t and I haven’t heard anyone else thing of one — that is not fine, then

```
git checkout master
git merge --no-commit develop

```

will show what the problem is and

```
git reset --hard HEAD

```

will put `develop` back into its state when `bugfix/revert_string` was merged into it. At that point, we can fix `develop` however we need to before trying to merge it into `master` again.

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 14, 2017, 10:03pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/63 "2017-11-14T22:03:56Z")

</div>

The StanHeaders repo typically points to the master branches of its two submodules, although that is ordinarily the latest tagged commit anyway. The StanHeaders R package that goes on to CRAN is a bit different to avoid breaking some other R packages.

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 14, 2017, 10:05pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/64 "2017-11-14T22:05:15Z")

</div>

I don’t trust `-Xtheirs` - it broke one test that you detected, for example. I think we’d have to manually inspect all of the merge conflicts.

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 14, 2017, 10:07pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/65 "2017-11-14T22:07:00Z")

</div>

OK but that is tantamount to saying you don’t trust our tests either.

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 14, 2017, 10:10pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/66 "2017-11-14T22:10:14Z")

</div>

I disagree - these conflicts alter the tests from the state in which I trust them.

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 14, 2017, 10:12pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/67 "2017-11-14T22:12:59Z")

</div>

You don’t have to trust that the tests compile (which they don’t in one case). You just have to trust that when the tests compile and pass, the code is not in a worse shape than it was when it passed previously.

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 14, 2017, 10:17pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/68 "2017-11-14T22:17:22Z")

</div>

Right - I don’t trust that if there are uninspected changes to the tests.

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 14, 2017, 10:26pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/69 "2017-11-14T22:26:23Z")

</div>

```
git checkout revert_string
git merge -s recursive -Xtheirs --no-commit develop
git diff --ignore-space-change develop test/

```

Unfortunately, I can’t convince git to ignore added newlines at the end of files, but here they are:

```
diff --git a/test/unit/math/prim/mat/err/check_greater_or_equal_test.cpp b/test/unit/math/prim/mat/err/check_greater_or_equal_test.cpp
index 7f3f0b9594..bbac02e37f 100644
--- a/test/unit/math/prim/mat/err/check_greater_or_equal_test.cpp
+++ b/test/unit/math/prim/mat/err/check_greater_or_equal_test.cpp
@@ -220,3 +220,4 @@ TEST(ErrorHandlingScalar, CheckGreaterOrEqual_nan) {
     }
   }
 }
+ 
diff --git a/test/unit/math/prim/mat/err/check_greater_test.cpp b/test/unit/math/prim/mat/err/check_greater_test.cpp
index 5528a85b89..7a952182f9 100644
--- a/test/unit/math/prim/mat/err/check_greater_test.cpp
+++ b/test/unit/math/prim/mat/err/check_greater_test.cpp
@@ -181,3 +181,4 @@ TEST(ErrorHandlingScalar, CheckGreater_nan) {
   EXPECT_THROW(check_greater(function, "x", nan, nan),
                std::domain_error);
 }
+ 
diff --git a/test/unit/math/prim/mat/err/check_less_or_equal_test.cpp b/test/unit/math/prim/mat/err/check_less_or_equal_test.cpp
index 689f085764..3ce01e99c8 100644
--- a/test/unit/math/prim/mat/err/check_less_or_equal_test.cpp
+++ b/test/unit/math/prim/mat/err/check_less_or_equal_test.cpp
@@ -184,3 +184,4 @@ TEST(ErrorHandlingScalar, CheckLessOrEqual_nan) {
     }
   }
 }
+  
diff --git a/test/unit/math/prim/mat/err/check_pos_definite_test.cpp b/test/unit/math/prim/mat/err/check_pos_definite_test.cpp
index c93fe81f55..7eda6b3958 100644
--- a/test/unit/math/prim/mat/err/check_pos_definite_test.cpp
+++ b/test/unit/math/prim/mat/err/check_pos_definite_test.cpp
@@ -246,3 +246,4 @@ TEST_F(ErrorHandlingMatrix, checkPosDefinite_nan) {
                    std::domain_error,
                    expected_msg.str());
 }
+
diff --git a/test/unit/math/prim/scal/err/check_2F1_converges_test.cpp b/test/unit/math/prim/scal/err/check_2F1_converges_test.cpp
index cba19861d8..e8f7a0903d 100644
--- a/test/unit/math/prim/scal/err/check_2F1_converges_test.cpp
+++ b/test/unit/math/prim/scal/err/check_2F1_converges_test.cpp
@@ -87,3 +87,5 @@ TEST(passesOnConvergentArgs, Check2F1Converges) {
   EXPECT_NO_THROW(check_2F1_converges(function, a1, a2, b1, z));
   EXPECT_NO_THROW(check_2F1_converges(function, a1, a2, b1, z));
 }
+
+ 
diff --git a/test/unit/math/prim/scal/err/check_3F2_converges_test.cpp b/test/unit/math/prim/scal/err/check_3F2_converges_test.cpp
index 0985b5f8d7..2eda12d7fd 100644
--- a/test/unit/math/prim/scal/err/check_3F2_converges_test.cpp
+++ b/test/unit/math/prim/scal/err/check_3F2_converges_test.cpp
@@ -116,3 +116,5 @@ TEST(passesOnConvergentArgs, Check3F2Converges) {
   EXPECT_NO_THROW(check_3F2_converges(function, a1, a2, a3, b1, b2, z));
   EXPECT_NO_THROW(check_3F2_converges(function, a1, a2, a3, b1, b2, z));
 }
+
+ 
diff --git a/test/unit/math/prim/scal/err/check_greater_or_equal_test.cpp b/test/unit/math/prim/scal/err/check_greater_or_equal_test.cpp
index 7e6d7dd8c2..22c27fa957 100644
--- a/test/unit/math/prim/scal/err/check_greater_or_equal_test.cpp
+++ b/test/unit/math/prim/scal/err/check_greater_or_equal_test.cpp
@@ -51,3 +51,4 @@ TEST(ErrorHandlingScalar, CheckGreaterOrEqual_nan) {
   EXPECT_THROW(check_greater_or_equal(function, "x", nan, nan),
                std::domain_error);
 }
+ 
diff --git a/test/unit/math/prim/scal/err/check_greater_test.cpp b/test/unit/math/prim/scal/err/check_greater_test.cpp
index 976055d038..90d2ae2fa4 100644
--- a/test/unit/math/prim/scal/err/check_greater_test.cpp
+++ b/test/unit/math/prim/scal/err/check_greater_test.cpp
@@ -48,3 +48,4 @@ TEST(ErrorHandlingScalar, CheckGreater_nan) {
   EXPECT_THROW(check_greater(function, "x", nan, nan),
                std::domain_error);
 }
+ 
diff --git a/test/unit/math/prim/scal/err/check_less_or_equal_test.cpp b/test/unit/math/prim/scal/err/check_less_or_equal_test.cpp
index 5a966388b0..fbf38d6a8c 100644
--- a/test/unit/math/prim/scal/err/check_less_or_equal_test.cpp
+++ b/test/unit/math/prim/scal/err/check_less_or_equal_test.cpp
@@ -51,3 +51,4 @@ TEST(ErrorHandlingScalar, CheckLessOrEqual_nan) {
   EXPECT_THROW(check_less_or_equal(function, "x", nan, nan),
                std::domain_error);
 }
+  
diff --git a/test/unit/math/rev/scal/err/check_less_or_equal_test.cpp b/test/unit/math/rev/scal/err/check_less_or_equal_test.cpp
index b2208b0b95..27852a3d10 100644
--- a/test/unit/math/rev/scal/err/check_less_or_equal_test.cpp
+++ b/test/unit/math/rev/scal/err/check_less_or_equal_test.cpp
@@ -65,3 +65,4 @@ TEST(AgradRevErrorHandlingScalar, CheckLessOrEqualVarCheckUnivariate) {
 
   stan::math::recover_memory();
 }
+
diff --git a/test/unit/math/rev/scal/err/check_not_nan_test.cpp b/test/unit/math/rev/scal/err/check_not_nan_test.cpp
index 3db6717f64..6877f1cc2b 100644
--- a/test/unit/math/rev/scal/err/check_not_nan_test.cpp
+++ b/test/unit/math/rev/scal/err/check_not_nan_test.cpp
@@ -73,3 +73,4 @@ TEST(ErrorHandlingScalar, CheckNotNanVarCheckUnivariate) {
 
   stan::math::recover_memory();
 }
+

```

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 14, 2017, 10:37pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/70 "2017-11-14T22:37:07Z")

</div>

Those look like pretty innocuous changes. How does StanHeaders get released? Is it like a script that a person fires off on demand and it right now is programmed to always pull down Stan’s `master`?

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 15, 2017, 1:46am UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/71 "2017-11-15T01:46:34Z")

</div>

In principle, I just go into the StanHeaders folder of the rstan repo, update the submodules to master, and execute

```
R CMD build StanHeaders # makes StanHeaders_2.17.1.tar.gz
R CMD check StanHeaders_2.17.1.tar.gz

```

upload to [https://win-builder.r-project.org/](https://win-builder.r-project.org/) to see if it works on Windows and then upload to [https://xmpalantir.wu.ac.at/cransubmit/](https://xmpalantir.wu.ac.at/cransubmit/) .

In practice, it there are additional steps:

```
mv StanHeaders_2.17.1.tar.gz /tmp
cd /tmp
tar -xzf StanHeaders_2.17.1.tar.gz
# Fix broken things
R CMD build StanHeaders
R CMD check StanHeaders_2.17.1.tar.gz

```

and upload to [https://xmpalantir.wu.ac.at/cransubmit/](https://xmpalantir.wu.ac.at/cransubmit/) .

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [November 16, 2017, 4:46pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/72 "2017-11-16T16:46:40Z")

</div>

Gotcha. Would it be hard to just update the submodules to a `v2.17.1` tag instead of master? I have a branch with the full test suite run against just the relevant commits to fix the performance (and make the tests pass) here: [https://github.com/stan-dev/math/pull/674](https://github.com/stan-dev/math/pull/674)

I wouldn’t merge that in anywhere; instead I’d just tag it and make a release based on it in github. The release scripts also rely on master in quite a few places so it’d be a little manual.

I still have this fear based on ignorance and related but different bad past experiences with cherry-picking and that kind of thing that makes me prefer this, but if you’re pretty sure about merging this branch into master I’d go ahead and do it. Any tests you recommend running on the branch that can lend me confidence?

---

<div class="post-metadata">

**Author:** ![Henrik\_Singmann](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/henrik_singmann/32/119_2.png) [@Henrik\_Singmann](https://discourse.mc-stan.org/u/Henrik_Singmann)\
**Post date:** [November 30, 2017, 2:39pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/73 "2017-11-30T14:39:58Z")

</div>

Is there an expected timeline when the new version of `StanHeaders` and `rstan` will be submitted to CRAN?

---

<div class="post-metadata">

**Author:** ![bgoodri](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bgoodri/32/4451_2.png) [@bgoodri](https://discourse.mc-stan.org/u/bgoodri)\
**Post date:** [November 30, 2017, 3:56pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/74 "2017-11-30T15:56:43Z")

</div>

I think we are going to discuss it today.

---

<div class="post-metadata">

**Author:** ![Henrik\_Singmann](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/henrik_singmann/32/119_2.png) [@Henrik\_Singmann](https://discourse.mc-stan.org/u/Henrik_Singmann)\
**Post date:** [December 6, 2017, 10:17am UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/75 "2017-12-06T10:17:32Z")

</div>

Is there any news on the question when we can expect the next version?  
Sorry to be so insistent about it, but I would really like to use Stan with an LKJ prior that has correct constants.

---

<div class="post-metadata">

**Author:** ![mike-lawrence](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/mike-lawrence/32/59_2.png) [@mike-lawrence](https://discourse.mc-stan.org/u/mike-lawrence)\
**Post date:** [December 6, 2017, 2:29pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/76 "2017-12-06T14:29:05Z")

</div>

If I read the thread on the lkj bug correctly, it only applied to the rare scenario of using the lkj for random number generation. If it affected using the lkj as I prior, I presume there’d be much more panic to get the fix out since lkj is the recommended prior for models with correlations.

---

<div class="post-metadata">

**Author:** ![Henrik\_Singmann](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/henrik_singmann/32/119_2.png) [@Henrik\_Singmann](https://discourse.mc-stan.org/u/Henrik_Singmann)\
**Post date:** [December 7, 2017, 10:54am UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/77 "2017-12-07T10:54:56Z")

</div>

As far as I know it only affects the calculation of marginal likelihoods and Bayes factors (e.g., as implemented in our `bridgesampling` package) not estimation or random number generation. So it is true that it is not very common, but it is still unfortunate that the bug exists for such a long time in the version available on CRAN.

---

<div class="post-metadata">

**Author:** ![syclik](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/syclik/32/6_2.png) [@syclik](https://discourse.mc-stan.org/u/syclik)\
**Post date:** [December 7, 2017, 8:23pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/78 "2017-12-07T20:23:15Z")

</div>

We discussed this briefly at the Stan meeting today. I’ll try to summarize where we’re at and what we want to accomplish.

**Summary**

Our current release, v2.17.0, is slow. But it can be compiled with a compiler that’s pre-C++11.

Current state of `develop` requires a C++11 capable compiler.

Two suggestions:

1. Release v2.17.1 that fixes the slowness and does not require C++11.
2. Release v2.18.0 that fixes the slowness and requires C++11.

The difficulty with releasing v2.17.1 is due to conflicts, which is no longer an issue since @bgoodri has fixed it on a branch.

**Decision**

1. Are we releasing a v2.17.1 or v2.18.0?  
@seantalts and @bgoodri, I think you two are the key stakeholders in the first decision.
2. When are we releasing it?  
@seantalts, you’re the key stakeholder here.

@seantalts and @bgoodri, mind discussing it? (if it were my decision, I’d just move forward with v2.18.0 and keep development moving forward)

---

<div class="post-metadata">

**Author:** ![seantalts](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/seantalts/32/32_2.png) [@seantalts](https://discourse.mc-stan.org/u/seantalts)\
**Post date:** [December 8, 2017, 1:08am UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/79 "2017-12-08T01:08:13Z")

</div>

I think from my perspective I’m still waiting to hear back from Ben on my last post in this thread. I have a 2.17.1 branch we can tag as 2.17.1 and release for CmdStan immediately, but merging that branch into master causes me some slight concern that maybe Ben can ameliorate. I’m also happy to do a normal 2.18.0.

---

<div class="post-metadata">

**Author:** ![syclik](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/syclik/32/6_2.png) [@syclik](https://discourse.mc-stan.org/u/syclik)\
**Post date:** [December 8, 2017, 3:55pm UTC](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442/80 "2017-12-08T15:55:49Z")

</div>

> [@seantalts](#):
>
> Gotcha. Would it be hard to just update the submodules to a v2.17.1 tag instead of master? I have a branch with the full test suite run against just the relevant commits to fix the performance (and make the tests pass) here: [[Ignore] by seantalts · Pull Request #674 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/674)
> 
> I wouldn’t merge that in anywhere; instead I’d just tag it and make a release based on it in github. The release scripts also rely on master in quite a few places so it’d be a little manual.
> 
> I still have this fear based on ignorance and related but different bad past experiences with cherry-picking and that kind of thing that makes me prefer this, but if you’re pretty sure about merging this branch into master I’d go ahead and do it. Any tests you recommend running on the branch that can lend me confidence?

@bgoodri, can you respond to this comment from @seantalts?

@seantalts, I think to answer your first question: if we tag `v2.17.1` and that’s our latest version, we should just have `master` point to it. (Unless I’m missing a deeper point, but `master` should just always point to our latest tag?)

[Previous page](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442.md?page=3)

[Next page](https://discourse.mc-stan.org/t/new-v2-17-1-release-for-math-and-stan/2442.md?page=5)