Release ggplot2 3.3.0

[thomasp85]

Prepare for release:

• Check current CRAN check results
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• revdepcheck::revdep_check(num_workers = 4)
• Update cran-comments.md
• Polish NEWS
• Review pkgdown reference index for, e.g., missing topics
• Draft blog post

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Finish blog post
• Tweet
• Add link to blog post in pkgdown news menu

[thomasp85]

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!

[clauswilke]

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? :-)

[thomasp85]

I can try to look at it. If I fold I don’t think it is reasonable to wait for it

[clauswilke]

Agreed. This is not a showstopper issue, and we should not delay the release over it.

[yutannihilation]

Should #3498 be fixed before the release? I feel it should be but am not sure how difficult to get it done.

[thomasp85]

I think it should (if possible)

[yutannihilation]

Sure.

[yutannihilation]

Can we tag the release after the blog post is linked in _pkgdown.yml? (And, hopefully, I hope I don't need to build the stable site manually this time... c.f. #3482)

#3622

[paleolimbot]

Given that there were some major changes in the Scale and Coord systems, I think anything that might cause compatibility issues should maybe get handled prior to release. I browsed the issues and PRs, and I think that (1) moving break censoring to guide_train() (to support PRs such as #3591), (2) using the R6 ranges from the scales package (#2710), and (3) fixing the zero break on scale_*_sqrt() (#980) fit into this category. If there's a consensus that this should be fixed before the release, I'd be happy to work up a PR fixing all three.

[thomasp85]

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?

[hadley]

I think it's basically too late in the cycle to tackle them; they'd all be good candidates for the next version though.

[paleolimbot]

It's no prob, happy to tackle them later. I was mostly thinking about #3566 (comment) when suggesting those 3.

[thomasp85]

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

[thomasp85]

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/

[yutannihilation]

@thomasp85
Your blog post made me aware that NEWS.md is missing a bullet for bi-directional geoms and stats. Could you add one? (Thanks for the nice post anyway, I didn't come up with a minimal example to explain how useful stage(), after_scale(), after_stat() are!)

[thomasp85]

Oh - god catch... I'll add it

[paleolimbot]

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.

[yutannihilation]

@thomasp85 Are there anything I can help about the release process? (e.g. investigating the revdep results?)

[thomasp85]

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

[yutannihilation]

Sure, I'll look into #3808

[thomasp85]

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

[thomasp85]

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?

[yutannihilation]

@thomasp85
Thanks for working on the release!

In a usual workflow, I think these steps are enough

1. Merging a RC branch into master without bumping the version
2. Add the blog post to _pkgdown.yml on master
3. Bump version on master

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.

[thomasp85]

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

[hadley]

ggplot2 is the only package that routinely uses RC branches so any usethis functions are likely to come from y'all 😄

[thomasp85]

Damn... there is no such thing as a free meal...

[yutannihilation]

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...

[thomasp85]

How is the main pkgdown site build being triggered?

[yutannihilation]

By default, Travis's deploy is triggered when on master.

branch: name of the branch. If omitted, this defaults to the app-specific branch, or master.(https://docs.travis-ci.com/user/deployment#conditional-releases-with-on)

So, we need a tweak like this c616035 to trigger the build on non-master branch.

Whether the built site will go to /dev/ or not is determined by this logic:

https://pkgdown.r-lib.org/reference/build_site.html#development-mode

[thomasp85]

@yutannihilation can you do your magic and build the pkgdown off of the last release?

[yutannihilation]

Sure.

[yutannihilation]

Done by this commit: 0b4852c

[yutannihilation]

As the pkgdown site is updated, I think we can close this issue. 🎉

https://ggplot2.tidyverse.org/