Beta (testing) periods for candidate releases

[TimTaylor]

Will you consider doing beta (testing) periods for ggplot2 releases? I've found in the past with ggplot2 that my CI hasn't been good enough to catch small changes (e.g. deprecation warnings) so it would be good to catch these things in advance.

I'm aware I can test the main branch but having a release candidate would make things more focussed.

Hope this makes sense. Cheers for the continued development.

[teunbrand]

We typically split off a release candidate once we're tinkering with the last steps of the release and want to continue development on the main branch. This makes these release candidates very ephemeral. We try to inform people of reverse dependency failures 2 weeks prior to releasing a new version, so arguably that is the beta testing period. Is there something more formal you're proposing?

[TimTaylor]

Is there something more formal you're proposing?

Probably just flagging of the commit or branch to test in some additional form of announcement.

I think where I've been caught out in the past is deprecation warnings displayed in some rendered output. Like I say, likely a weakness in my own CI, but a small heads up to test a certain commit/branch would be appreciated and, hopefully, not too burdensome. How best to deliver the heads up (socials?), I'm not sure.

[teunbrand]

I'll discuss with Thomas, but while we got you here: we're planning a release soon so testing now would be ideal!

[TimTaylor]

I'll discuss with Thomas, but while we got you here: we're planning a release soon so testing now would be ideal!

Just have ;-). All good AFAICT!

[teunbrand]

We decided not to change anything about our release process, as it is involved enough as it is.
The main issue we have with a longer time for a release candidate to exist is that the longer we wait, the more new packages depending on ggplot2 are released.
It has happened a few times already that we thought we had adressed all reverse dependency issues, only to discover that a new package was submitted that introduced another incompatibility.
This is sort of unavoidable, but the idea of a 'release candidate' might instill a false sense of confidence in people.

We're happy to improve the messaging around a new release, but we're unsure what the appropriate venues are. Pinning an issue on GitHub as a message board kind of thing? Announcing it on socials (who should do the announcing)? Emailling every reverse dependency seems like overkill to us.