thisisnic edited a comment on issue #10: URL: https://github.com/apache/arrow-cookbook/issues/10#issuecomment-894213354
> First, it would probably be good if each implementation had the freedom to adopt a strategy that works for them... Agreed Thinking specifically about the R cookbook then: > 1... I don't think this would be suitable for the R version of the cookbook, as the API is growing in features at the moment, and it may be the case that users work for organisations which aren't going to let them keep up with the 3 monthly release cycle - this could be confusing when readers are faced with content which doesn't work for them. > 2... I thought about this - it would make reordering content complicated, and I don't know if that's an issue or not. I don't think it'd be too hard to implement though. > 3... This approach sounds closer to what I was thinking, but could be tricky to implement in terms of integrating it with `bookdown`. > The one approach I think we should NOT do... Yeah, agreed, I think we need to be able to have something for the current version (nightlies) How about this approach: 4. a modified version of 3: * instead of a dropdown, multiple versions of the cookbook are built, and so the URL for the main page is e.g. `whatever/arrow-cookbook/r/5.0.0/index.html`. Therefore, the differing functionality is kept separate to prevent confusing readers. * the content relating to the upcoming release is merged into `main`, which builds against the nightlies, and once a release has been done, that version of the cookbook gets its own branch. * admittedly, there is a bit of extra work when a new PR is merged, as it would be necessary to create additional PRs to add the content to previous versions if the recipe works on those. I suppose this extra workload might be higher at first, but as time goes on and more recipes are added, new content is more likely to be applicable only to new features rather than existing ones * with each release, we add a new CI job for that release. I suppose a potential issue is this getting potentially huge, but we could choose to adopt a strategy like "freezing" older cookbooks so that new recipes are never added to them and so they don't need to be rebuilt, and only building against the most recent patch for each major release. -- 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
