Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git branching workflow for use_release_issue()? #1884

Open
2 tasks
kevinushey opened this issue Aug 10, 2023 · 6 comments
Open
2 tasks

git branching workflow for use_release_issue()? #1884

kevinushey opened this issue Aug 10, 2023 · 6 comments
Labels
feature a feature request or enhancement release 🛫

Comments

@kevinushey
Copy link
Contributor

Using rstudio/renv#1634 as a template, I wonder if we should also suggest starting with something like:

  • Create and switch to release branch release/<version>

Then, follow the regular steps. After building and submitting to CRAN, if the submission is accepted, we can then:

  • Merge release branch to main

And then run the regular steps. Does that make sense?

@gadenbuie
Copy link
Contributor

This is also what we do for Shiny for R, although we follow the branch naming convention of rc-vX.Y.Z. I personally really like this workflow.

One thing to watch out for is that you have to merge the release branch into the main branch in a way that preserves the git history if you want to tag the commit that was sent to CRAN (i.e. use a merge commit). If you're used to a squash merge workflow or don't mind tagging a different commit than the exact one sent to CRAN, you might need to remove the CRAN-SUBMISSION file created by submit_cran() before calling use_github_release().

@gadenbuie
Copy link
Contributor

gadenbuie commented Aug 17, 2023

A common thread between this and #1887 in my work is that I would appreciate the ability to customize the release issue in a more detailed way. Currently, release_bullets() adds steps to the end of "Prepare for release", but a branching workflow or a workflow that requires additional checks might benefit from customizing where the todo items appear in the list.

One option would be to allow release_bullets() to return a named list such that items can be added to specific places in the release checklist, e.g. "prepare-start", "pre-check", "post-check", etc. This could be backwards compatible in that an unnamed list would be assumed to be "prepare-end" (at the end of the prepare section).

If there's interest in this approach, I'd be happy to work up a PR.

@hadley
Copy link
Member

hadley commented Nov 3, 2023

I'd be happy to make this the default workflow, assuming we can automate the steps sufficiently that I can follow the checklist without having to think about it. Maybe it's sufficient to add pr_init(), pr_push(), and pr_finish() in the appropriate places? I think it would be useful with a concrete proposal there.

(@gadenbuie we're tracking the issue of adding bullets anywhere in #1818, but I do think it's important to standardise as much as possible on one process)

cc @DavisVaughan since I know this is something he has also asked for, and @thomasp85 since I think we do generally use a branch for ggplot2 releases.

@hadley hadley added feature a feature request or enhancement release 🛫 labels Nov 3, 2023
@DavisVaughan
Copy link
Member

@hadley I have done that actually. It is probably a little out of date now but I did it here business-science/tibbletime#104, so we could maybe pull that over?

@hadley
Copy link
Member

hadley commented Nov 3, 2023

Yeah, that seems like a good start. Want to do a PR? (I'd leave the change in revdeps for now since we should discuss that elsewhere)

@hadley
Copy link
Member

hadley commented Oct 7, 2024

More discussion in #1946

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement release 🛫
Projects
None yet
Development

No branches or pull requests

4 participants