@syclik You’re talking about this workflow right? I went ahead and tagged a
release-2.17.0 branch in
stan following that workflow. I can take care of merging remaining PRs that we want in this release into that branch and then eventually into
master where I can tag the 2.17.0 release. I’ll then merge this branch back into
develop in case there are commits there that weren’t merged into develop.
To support this, I’m going to change the base branch on the pull requests that I know are important for 2.17.0, which at this point is maybe just the boost 1.64.0 one? This is as simple as choosing the new release branch, which someone should do for things that should go into 2.17.0:
Let me know if anyone has issues with this! We don’t necessarily have to follow this going forward, but it’s a nice tool / framework for cases like this.