Skip to content

Binary R-devel Builds For OS-X

5 messages · brodie gaslam, Peter Dalgaard, Simon Urbanek

Original
brodie gaslam
# 
At Peter Daalgard's suggestion, I'm moving a thread about compiling / obtaining R-devel or R-alpha/RC OS-X binaries for OS-X to this mailing list.? As per Kylie Bemis it looks like nightlies are already produced at http://mac.r-project.org/ and the updated compilation instructions http://mac.r-project.org/tools/ look great (last time I looked into this I balked at installing Fortran from brew).

Presumably the alpha/RC releases are also posted to the mac.r-project.org page.

The idea is to encourage folks to test R-devel in their normal workflow.

Best,

B.
On Friday, May 15, 2020, 1:29:30 PM EDT, peter dalgaard <pdalgd at gmail.com> wrote:
To discuss this further, we should probably move over to R-sig-mac and change the subject header.

-pd

  
    

      
      
    

  


  


    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Yes. Simon's policy is just to use the current x.y SVN branch (say R-4.0-branch) which goes through the alpha-beta-RC-(release)-Patched cycle. 

I.e. R-4.0-branch.pkg will _be_ the prerelease at the relevant stage of the development cycle.

(Nerdy details: There is only x.y.0 alpha, otherwise we go directly from, say, "4.0.0 Patched" to "4.0.1 beta"; or, differently put, R-patched _is_ the alpha for the next version. Also, the unqualified x.y.z name is only there while the relase tarball is being created, which is about 5 minutes on release day so never makes it to the nightly builds.)  

-pd

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
12 days later

    

      
      

        


  

        

      brodie gaslam
    

    

      
      #
    

  


  

      
I just installed the 4.0 patched binary, and noticed that it is still at 5/24 (i.e. pre Beta, although I'm guessing that's a minor distinction).? 3.6 was updated yesterday.? Since I'm not too familiar with this process yet, what kind of update schedule should I expect for these binaries?

Best,

Brodie.

        
On Saturday, May 16, 2020, 4:22:40 AM EDT, peter dalgaard <pdalgd at gmail.com> wrote:

        
Yes. Simon's policy is just to use the current x.y SVN branch (say R-4.0-branch) which goes through the alpha-beta-RC-(release)-Patched cycle. 

I.e. R-4.0-branch.pkg will _be_ the prerelease at the relevant stage of the development cycle.

(Nerdy details: There is only x.y.0 alpha, otherwise we go directly from, say, "4.0.0 Patched" to "4.0.1 beta"; or, differently put, R-patched _is_ the alpha for the next version. Also, the unqualified x.y.z name is only there while the relase tarball is being created, which is about 5 minutes on release day so never makes it to the nightly builds.)? 

-pd

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Simon is the one who has the full detail, but at this point, I get 

R version 4.0.1 beta (2020-05-28 r78607) -- "See Things Now"

According to mac.r-project.org, this was built at 19:29 on May 28. It's not really clear what time zone that is... The transition to beta was just after midnight CET on the 27th which is like 10AM in Auckland, so you'd expect it to be picked up for the May 27 build, but maybe something got stalled. Or there might be a delay between the SVN checkout and the .pkg build.

-pd

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Our build is currently a bit in flux since I was moving the CRAN machines back to the university. Also for the betas I am notarising the builds which includes a manual step (I don?t do that for the regular nightlies).

FWIW the time zone of the build machine is US/Eastern for historical reasons.

Cheers,
Simon