Update news for simtrial 0.4.0

[LittleBeannie]

No description provided.

[jdblischak]

In the future, when we need to rush a CRAN release to fix a problem identified by the CRAN team, we may want to consider creating a release branch that starts from the previous release, and only address the specific concern. I feel like we are still in the middle of the development of sim_gs_n() and its related functions, so it's a bit of an awkward time to release these features to CRAN when we know we are planning to continue to change them in the very near future.

[nanxstats]

In the future, when we need to rush a CRAN release to fix a problem identified by the CRAN team, we may want to consider creating a release branch that starts from the previous release, and only address the specific concern. I feel like we are still in the middle of the development of sim_gs_n() and its related functions, so it's a bit of an awkward time to release these features to CRAN when we know we are planning to continue to change them in the very near future.

I agree. This is a good suggestion and let's consider this approach if similar situations happen again. I'm just curious about how to not have a long-lived branch, and still getting that into the main branch history, with the correct history order 🤔

Ideally, we should make more progressive but smaller releases, to not surprise people by making very few big releases, but I understand that type of release schedule might not be a good fit for all projects.

These comments are now properly addressed

[jdblischak]

I agree. This is a good suggestion and let's consider this approach if similar situations happen again. I'm just curious about how to not have a long-lived branch, and still getting that into the main branch history, with the correct history order 🤔

We wouldn't merge the release branch into main. We would apply the same fix to the release branch, in this case something like release-0.3, and main. Then on the release branch we would bump the version number, update NEWS, tag/release, and submit to CRAN. Once 0.4 is submitted to CRAN, then we could simply delete release-0.3 (the tag would still exist if we ever needed to resurrect the branch for some edge case).

Ideally, we should make more progressive but smaller releases, to not surprise people by making very few big releases, but I understand that type of release schedule might not be a good fit for all projects.

I don't feel like {simtrial} is yet at the right stage of development for progressive smaller releases. We are still experimenting with new features and how best to implement them. Submitting a version to CRAN with an exported function implies a certain level of stability (that will be maintained for at least the short-term). I think we want to maintain the flexibility and freedom to continue shaping the APIs of new functions like sim_gs_n(), multitest(), maxcombo(), etc.

[nanxstats]

We wouldn't merge the release branch into main. We would apply the same fix to the release branch, in this case something like release-0.3, and main. Then on the release branch we would bump the version number, update NEWS, tag/release, and submit to CRAN. Once 0.4 is submitted to CRAN, then we could simply delete release-0.3 (the tag would still exist if we ever needed to resurrect the branch for some edge case).

I see. Looks like the only side effect is that we will have a "nonlinear" Git history. It would be a bit harder to figure out what happened with bisecting and tracking the exact order of changes. But as you mentioned, good documentation, tagging, and communication should be helpful.

[jdblischak]

Looks like the only side effect is that we will have a "nonlinear" Git history.

True. The hypothetical tag v0.3.3 in my diagram above would not be in the primary development trunk (ie the main branch)

It would be a bit harder to figure out what happened with bisecting and tracking the exact order of changes.

I don't think this should be an issue. I am not advocating for long-living feature branches or anything like that. This is only for minor changes like the recent removal of {bshazard}. And that same change is applied to the main branch, so it would be there for bisecting/tracking purposes. The only time the Git diff would be more complex would be if you explicitly compared the tag v3.3.2 to main.

And you have to remember the huge gain achieved by this practice. It allows us to decide our release cadence based on the maturity of our new features instead of when some CRAN issue inevitably happens to arise.