thisisnic edited a comment on issue #10: URL: https://github.com/apache/arrow-cookbook/issues/10#issuecomment-896223385
> Do you think the different cookbooks need to align on how they approach this? Not at all, I'd be actively opposed to that as it'd be unnecessary. I think that the user bases may be vastly different for different Arrow implementations and this approach would be totally unnecessary for most. I'm basing my thinking off an assumption I'm making that the R package will have 2 main groups of users: 1. People building things on top of Arrow, those who are likely to use the lower-level functionality 2. People who are just using it for data analysis; in the R implementation they'd be mainly using the read/writing functions and `dplyr` syntax and not going anywhere near the lower-level stuff I think all Arrow implementations will have people from group 1, but R will have a higher proportion of people from group 2. My concern here is that it's very common in industry to encounter folks who are locked to certain package versions because of the strategy their IT department has chosen to handle R package management. > The question is then indeed how long we intent to maintain the "older" cookbooks? Because it sounds like a maintenance burden to actively maintain multiple versions ... I think there are lots of options for managing the maintenance here sensibly (e.g. freezing previous versions after every release and only updating them if someone cares enough to submit a PR at which point that CI job can run and that version updates, only going back ~6 major releases). > That might be a good reason, while the content is still growing in a faster pace, to not yet have separate versions. Sure - there'd only be 1 version right now anyway as I wasn't looking at writing content for Arrow versions before 5.0.0. I'm going to nudge some more of the R folk for their opinion, as I'm a bit torn about what the best answer is for the R implementation here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
