Well... The first rule of release management is not to have the same version number on different releases.
I see three possibilities (1) Tell users to use 4.0.1-patched if they need tcltk on Windows (2) A "vendor patch release": Windows maintainer reissues the binary after applying the critical patch. (3) 4.0.2 As soon as possible (realistically June 22nd-ish) Now, (1) requires no intervention, but it has the problem that we are approaching the time for campus-wide installations (insofar as campuses will actually reopen in Fall). It will be messy to have to tell IT not to use the officially released binary, and most likely they just won't. (2) is possible if we act quickly, although it leaves a "ghost version" of 4.0.1 around (and don't try renaming tricks, it can mess up CRAN scripts - some of us have the scars...). It should work but it is a bit iffy because the actual problem is in fact in the sources and it creates a situation where the binary and the sources are out of sync. (3) is clean, but it takes a while (minimum 12 days) to go through the release run-in. Also, for a new release, I suspect we want to have a closer look at the issue as we seem to be using multiple allocators on Windows in a, hmmm, "eclectic mix". (E.g. connections.c has both Calloc/Free and malloc/free combinations and AFAICT, the latter uses a different allocator.) -pd > On 8 Jun 2020, at 01:20 , Abby Spurdle <spurdl...@gmail.com> wrote: > > sorry, release "versions" > > > On Mon, Jun 8, 2020 at 11:17 AM Abby Spurdle <spurdl...@gmail.com> wrote: >> >> On Mon, Jun 8, 2020 at 4:09 AM Fox, John <j...@mcmaster.ca> wrote: >>> Does it make sense to withdraw the Windows R 4.0.1 binary until the issue >>> is resolved? >> >> Yes, it does. >> All the release reversions should be removed. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
