-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Release ggplot2 3.3.0 #3674
Comments
We are not beginning the release process just yet, but I'm opening this so we have a venue for coordination. The hard deadline for a release is RStudio::conf in late January, but I think we can easily get it out before that. @clauswilke, @yutannihilation, @hadley, @paleolimbot, @karawoo can you tag any open issues you deem necessary to get into this release. I don't think we should add any more features to the milestone, but if there is something of utmost importance, please make your case 🙂 We have already run a preliminary revdepcheck and fixed a couple of regressions. There are a number of maintainers that will need to update their packages because they depend on the old axis data structure. @hadley will send out mails to these. We will run an additional revdepcheck when all code in the milestone has been merged in. Don't work on this over the holidays if you can help it. You all deserve a break! |
I think issue #3557 would be a good candidate to complete before the release, though maybe it's too big of a job. It's about enabling markdown formatting in strip labels. I plan to release ggtext as soon as ggplot2 3.3.0 is out, and people will want to use it, and will find out that they can't use it for strip labels. The argument against finishing up #3557: I looked at the code and didn't find an easy way to do this. Maybe somebody else wants a challenge? :-) |
I can try to look at it. If I fold I don’t think it is reasonable to wait for it |
Agreed. This is not a showstopper issue, and we should not delay the release over it. |
Should #3498 be fixed before the release? I feel it should be but am not sure how difficult to get it done. |
I think it should (if possible) |
Sure. |
Given that there were some major changes in the |
None of these seems related to recent changes in the position scales. We have decided to wait a bit with 1) and the others are pretty old. What is the rationale for taking these on now? |
I think it's basically too late in the cycle to tackle them; they'd all be good candidates for the next version though. |
It's no prob, happy to tackle them later. I was mostly thinking about #3566 (comment) when suggesting those 3. |
I have created a release branch https://github.com/tidyverse/ggplot2/tree/v3.3.0-rc. Any changes that needs to get into v3.3.0 must be merged into this (there does not seem to be any pending issues that require code change in the milestone though) This also means that the master is open to merging in PRs we don't want for 3.3.0 |
I've created a draft release post. People are welcome to chime in if I haven't given their additions justice. PR: tidyverse/tidyverse.org#379, Preview: https://deploy-preview-379--tidyverse-org.netlify.com/blog/2020/01/ggplot2-3-3-0/ |
@thomasp85 |
Oh - god catch... I'll add it |
I added one tiny comment to the review post...it looks great! It's amazing to see the big picture, which the release post does an excellent job communicating. |
@thomasp85 Are there anything I can help about the release process? (e.g. investigating the revdep results?) |
You are very welcome to look into the revdepcheck checks. If you can focus on whether there are new problems compared to the last check |
Sure, I'll look into #3808 |
We are very close to getting ready to release. There is a single issue that I have a fix for, but waiting for some input from @hadley. Once that is done I'll start the release process |
ggplot2 has been send to CRAN 🤞 @yutannihilation what is the preferred way to ensure that the pkgdown site is updated when we work off of a rc branch? |
@thomasp85 In a usual workflow, I think these steps are enough
so that step 1 and 2 triggers the stable build. But, since our master branch is protected, we need approval for each merge, which feels a bit tiresome. So, now I come to think there's no way to build the stable site properly with a little effort... So, please ignore my comments above, I (or someone who is interested) will take care of it. |
Another issue is that the version is bumped on the RC branch since that is part of the release process... We need to begin thinking about better tooling when working with RC branches @hadley — I feel this should get better support in usethis |
ggplot2 is the only package that routinely uses RC branches so any usethis functions are likely to come from y'all 😄 |
Damn... there is no such thing as a free meal... |
Yeah, we need to invent a new workflow, and actually I've thought of it many times in this year or so, but couldn't come up with a nice idea... |
How is the main pkgdown site build being triggered? |
By default, Travis's deploy is triggered when on master.
So, we need a tweak like this c616035 to trigger the build on non-master branch. Whether the built site will go to https://pkgdown.r-lib.org/reference/build_site.html#development-mode |
@yutannihilation can you do your magic and build the pkgdown off of the last release? |
Sure. |
Done by this commit: 0b4852c |
As the pkgdown site is updated, I think we can close this issue. 🎉 |
Prepare for release:
devtools::check(remote = TRUE, manual = TRUE)
devtools::check_win_devel()
rhub::check_for_cran()
revdepcheck::revdep_check(num_workers = 4)
cran-comments.md
Submit to CRAN:
usethis::use_version('minor')
devtools::submit_cran()
Wait for CRAN...
usethis::use_github_release()
usethis::use_dev_version()
The text was updated successfully, but these errors were encountered: