Sync with the development branch of Stan

[hsbadr]

Summary:

This PR brings the develop branch to Stan v2.33+ (development).

Intended Effect:

Sync with the development branch of Stan, and create branches and tags of RStan/StanHeaders releases.

How to Verify:

GitHub Actions / Unit Tests / Local Tests

Side Effects:

N/A

Documentation:

N/A

Reviewer Suggestions:

@bgoodri @andrjohns

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

• Code: GPLv3 (https://opensource.org/licenses/GPL-3.0)
• Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[bgoodri]

Thanks @hsbadr . I'll review this once we get up to 2.32 and the other packages catch up to the new array syntax.

[hsbadr]

Thanks @hsbadr . I'll review this once we get up to 2.32 and the other packages catch up to the new array syntax.

@bgoodri Once you merge this, I'll create a PR for v2.32 based on it. We can adopt the new array syntax before the other packages. This is the development branch; the releases can be handled separately in new branches/tags. If you'd like to keep the CRAN version (currently v2.26) stable, update the master branch or create a new branch for it.

[andrjohns]

I also agree with @hsbadr's suggestion here, most people would expect develop to be the cutting-edge and releases to have their own branches/tags (which also what the other Stan repos do). Having a different structure could make things confusing for new devs/contributors who spend time on making patches for the wrong branch

[hsbadr]

I also agree with @hsbadr's suggestion here, most people would expect develop to be the cutting-edge and releases to have their own branches/tags (which also what the other Stan repos do). Having a different structure could make things confusing for new devs/contributors who spend time on making patches for the wrong branch

+1 This will also align our development efforts such as implementing pathfinder in RStan (see #1084 (comment)). I won't have to maintain the experimental branch (we can delete it after merging this PR), and any new changes can be reviewed in PRs to the develop branch.

[andrjohns]

@bgoodri are you happy with merging this? It would be great to get 2.32 to CRAN soon

@hsbadr which commit is the one that you'd consider v2.32? So I can run updated downstream checks

[hsbadr]

which commit is the one that you'd consider v2.32?

I'll create a branch for v2.32 from develop once this PR is merged.

[andrjohns]

This has now been open for ~3 weeks with no more engagement from @bgoodri, and it's blocking further 2.32 prep and general development, so I'm going to merge

[hsbadr]

which commit is the one that you'd consider v2.32?

@andrjohns Let's test StanHeaders_2.32 branch (artifacts).

I wanted to rename it release/v2.32.2 consistent with Stan repo, but reverted back to StanHeaders_*: 1) to avoid editing the GHA workflow, 2) this repo includes two packages, and 3) we might need to patch the Stan submodule.

[hsbadr]

Once v2.32 is on CRAN, we could update the master branch.

[andrjohns]

which commit is the one that you'd consider v2.32?

@andrjohns Let's test StanHeaders_2.32 branch (artifacts).

I wanted to rename it release/v2.32.2 consistent with Stan repo, but reverted back to StanHeaders_*: 1) to avoid editing the GHA workflow, 2) this repo includes two packages, and 3) we might need to patch the Stan submodule.

Perfect, thanks @hsbadr! I'll get on it!

[hsbadr]

I'll get on it!

Let me know when it's ready to host it in our R repo for testing.

[andrjohns]

@hsbadr after adding the changes in #1100, all downstream dependencies pass without issue for me