Adding an R pre-release (4.3) container

[almahmoud]

Container image name

rocker/r-ver:devel

Container image digest

rocker/r-ver@sha256:80ff23136c0f4b7c3342b2c408d2118b9bf7dd51aa08d69ef354f86d42189019

What operating system related to this question?

Linux

System information

No response

Question

Right now, the latest tag points to the R 4.2 while the devel tag points to the newest R 4.4 with no tag pointing to R 4.3 at the moment. I was wondering if it'd be possible to add a tag, perhaps called alpha, that would hold the R version that is close to release during the freeze period, so that the version remains available between when the new devel is out and the latest version is officially released.

[eddelbuettel]

Please talk to R Core; they do this to us each and every time. I think it affects rocker/r-devel and rocker/drd the same way. The good news it will all be sorted out in three weeks.

[eitsupi]

Thanks for opening this issue.

I think we need to write scripts for automatic detection and installation of alpha, beta, rc, etc., because they appear in the directory only for a very short period of time and their names are not consistent. https://github.com/rocker-org/rocker-versioned2/blob/3e683e870d2946156235f880074926d5d281d132/scripts/install_R_source.sh#L98-L112

For example, right now it looks like this

https://cloud.r-project.org/src/base-prerelease/

      Parent Directory                                      -   
      NOTICE.dates                     2010-03-23 09:54  490   
      R-alpha_2023-03-27_r84084.tar.gz 2023-03-27 22:21   33M  
      R-alpha_2023-03-28_r84109.tar.gz 2023-03-28 22:21   33M  
      R-alpha_2023-03-29_r84123.tar.gz 2023-03-29 22:21   33M  
      R-alpha_2023-03-31_r84131.tar.gz 2023-03-31 10:21   33M  
      R-alpha_2023-03-31_r84137.tar.gz 2023-03-31 22:21   33M  
      R-alpha_2023-04-01_r84141.tar.gz 2023-04-01 22:20   33M  
      R-alpha_2023-04-02_r84146.tar.gz 2023-04-02 22:20   33M  
      R-devel.tar.gz                   2023-04-02 23:20   33M  
      R-devel_2023-03-26_r84066.tar.gz 2023-03-26 23:22   33M  
      R-devel_2023-03-27_r84084.tar.gz 2023-03-27 23:21   33M  
      R-devel_2023-03-28_r84109.tar.gz 2023-03-28 23:21   33M  
      R-devel_2023-03-29_r84123.tar.gz 2023-03-29 23:21   33M  
      R-devel_2023-03-31_r84131.tar.gz 2023-03-31 11:20   33M  
      R-devel_2023-03-31_r84137.tar.gz 2023-03-31 23:22   33M  
      R-devel_2023-04-01_r84141.tar.gz 2023-04-01 23:20   33M  
      R-devel_2023-04-02_r84146.tar.gz 2023-04-02 23:20   33M  
      R-latest.tar.gz                  2023-04-02 22:20   33M  

Unlike devel and latest, it is not easy to capture alpha.

[eddelbuettel]

It is consistent in that they do the same process each year, and detail it here: https://developer.r-project.org/ (a super messy page with twenty year old stale stuff but the table at the top is current and you could check with the waybackmachine that it is the same four week alpha/beta/rc cycle reach time:

The schedule for 4.3.0 is as follows

Tuesday 2023-03-21: START
Friday 2023-03-24: GRAND-FEATURE FREEZE (4.3.0 alpha)
Friday 2023-04-07: FEATURE FREEZE (4.3.0 beta)
Friday 2023-04-14: CODE FREEZE (4.3.0 RC)
Tuesday 2023-04-18: PRERELEASE
Friday 2023-04-21: RELEASE (4.3.0)
The overall release schedule is to have annual x.y.0 releases in Spring, with patch releases happening on an as-needed basis. It is intended to have a final patch release of the previous version shortly before the next x.y.0 release.

[eitsupi]

@eddelbuettel Thanks for pointing that out.

But my main point of contention is that it is not possible to download from a fixed URL such as https://cran.r-project.org/src/base-prerelease/R-devel.tar.gz.

So, as you point out, I think it can be built if R-core makes it possible to publish the alpha, etc. with fixed URLs. (Perhaps it already exists?)

[eddelbuettel]

I think so. On either Peter's ftp site in Kopenhagen or in Vienna. Identifiable by different tarball names with the label in them.I have old commented-out / unused code in debian/rules for the archives, I never bothered automating detection. I used to just run weekly builds (but won't right now because we're in a freeze so even less likely anybody would use these).

[almahmoud]

Unless I am missing something (which I very well might be as I am a baby in this ecosystem), isn't https://cran.r-project.org/src/base-prerelease/R-latest.tar.gz for the pre-release? And all the code for it seems to already exist with the patched tag in the script, there just aren't Dockerfiles/target for that container?

I was able to build an r-ver container for 4.3.0 by setting R_VERSION=patched and building. I was hoping (unless I'm missing something) that a pre-release tag (probably better than alpha as I previously suggested) using R_VERSION=patched might work and would be the same as devel for most of the time, but diverge during the pre-release period?

[eddelbuettel]

Yes manually adjusting is the way to go if and when you have urgent production needs now. We will be back to normal proceeding "in an automagic manner" once R 4.3.0 is released.