Milestone4 (#55)

* Run ubuntu-release check first

This is the one I care about most of the time, so get it out of the way faster if possible.

* Update README for milestone 0.4.0

.github/workflows/R-CMD-check.yaml

@@ -18,10 +18,10 @@ jobs:
       fail-fast: false
       matrix:
         config:
+          - {os: ubuntu-latest,   r: 'release'}
           - {os: macos-latest,   r: 'release'}
           - {os: windows-latest, r: 'release'}
           - {os: ubuntu-latest,   r: 'devel', http-user-agent: 'release'}
-          - {os: ubuntu-latest,   r: 'release'}
           - {os: ubuntu-latest,   r: 'oldrel-1'}
 
     env:

DESCRIPTION

@@ -1,6 +1,6 @@
 Package: beekeeper
 Title: Rapidly Scaffold API Client Packages
-Version: 0.3.0.9000
+Version: 0.4.0
 Authors@R: c(
     person("Jon", "Harmon", , "[email protected]", role = c("aut", "cre", "cph"),
            comment = c(ORCID = "0000-0003-4781-4346")),

README.Rmd

@@ -53,10 +53,10 @@ Most of the outline was included in the grant proposal.
     - [x] The generated functions will work, but error checking, documentation, and tests will be minimal.
     - [x] **Potential challenges:** I'll need to strike a balance here between getting a basic working system and producing something that can be easily expanded later.
         -   **Update:** Also, this likely could go unsaid, but, if the API description is incorrect, the functions will not work as expected. Hopefully their error messages will be helpful for debugging, though!
-- [ ] **0.4.0: Batching and rate limiting.**
-    - [ ] Add documentation for implementing batching and rate-limiting. 
-    - [ ] If possible, export functionality to help implement these processes, but standards seem to vary widely.
-    - [ ] **Potential challenges:** This step will involve more reading and documenting than code, to gather examples of how different APIs implement limits and batching. It's possible systems will be so different that it will be difficult to summarize them. For example, Slack has two separate batching systems in its API, with some functions moved to the newer system, and others not. 
+- [x] **0.4.0: Batching and rate limiting.**
+    - [x] Add documentation for implementing batching and rate-limiting. 
+    - [x] If possible, export functionality to help implement these processes, but standards seem to vary widely.
+    - [x] **Potential challenges:** This step will involve more reading and documenting than code, to gather examples of how different APIs implement limits and batching. It's possible systems will be so different that it will be difficult to summarize them. For example, Slack has two separate batching systems in its API, with some functions moved to the newer system, and others not. 
         -   **UPDATE:** The [development version of {httr2}](https://github.com/r-lib/httr2/) has functionality to help with this quite a lot, thankfully! I'm skipping this milestone while that functionality stabilizes (this was previously 0.3.0).
 -   **0.5.0: More robust scaffolding.**
     -   Add parameter documentation.
@@ -97,6 +97,13 @@ Use `use_beekeeper()` to generate a `_beekeeper.yml` file, and then `generate_pk
 
 Read `vignette("beekeeper")` for more details.
 
+## The api2r package 'verse
+
+-   {beekeeper} (this package) is intended to help you rapidly create an R package that interfaces with a web API.
+-   [{nectar}](https://nectar.api2r.org) applies an opinionated framework around [{httr2}](https://httr2.r-lib.org/), aimed at making it easy to create standardized API-wrapping packages. Packages generated by {beekeeper} import functions from {nectar}, to avoid the relatively high dependency graph associated with {beeekeeper}.
+-   [{rapid}](https://rapid.api2r.org) converts OpenAPI descriptions of APIs to R objects. These objects are meant to provide a standardized starting point for {beekeeper} (and any future packages that generate R code from API specs, or, eventually, API specs from R code).
+-   [{anyapi}](https://anyapi.api2r.org) is intended to aid in the discovery of APIs. Eventually it may also auto-generate functions to interact with a newly discovered API, but that functionality is not yet implemented.
+
 ## Why "beekeeper"?
 
 A beekeeper is someone who tends to bees, and {beekeeper} is a package that helps you tend to APIs.

README.md

@@ -71,11 +71,11 @@ included in the grant proposal.
       description is incorrect, the functions will not work as expected.
       Hopefully their error messages will be helpful for debugging,
       though!
-- [ ] **0.4.0: Batching and rate limiting.**
-  - [ ] Add documentation for implementing batching and rate-limiting.
-  - [ ] If possible, export functionality to help implement these
+- [x] **0.4.0: Batching and rate limiting.**
+  - [x] Add documentation for implementing batching and rate-limiting.
+  - [x] If possible, export functionality to help implement these
     processes, but standards seem to vary widely.
-  - [ ] **Potential challenges:** This step will involve more reading
+  - [x] **Potential challenges:** This step will involve more reading
     and documenting than code, to gather examples of how different APIs
     implement limits and batching. It’s possible systems will be so
     different that it will be difficult to summarize them. For example,
@@ -140,6 +140,24 @@ Use `use_beekeeper()` to generate a `_beekeeper.yml` file, and then
 
 Read `vignette("beekeeper")` for more details.
 
+## The api2r package ’verse
+
+- {beekeeper} (this package) is intended to help you rapidly create an R
+  package that interfaces with a web API.
+- [{nectar}](https://nectar.api2r.org) applies an opinionated framework
+  around [{httr2}](https://httr2.r-lib.org/), aimed at making it easy to
+  create standardized API-wrapping packages. Packages generated by
+  {beekeeper} import functions from {nectar}, to avoid the relatively
+  high dependency graph associated with {beeekeeper}.
+- [{rapid}](https://rapid.api2r.org) converts OpenAPI descriptions of
+  APIs to R objects. These objects are meant to provide a standardized
+  starting point for {beekeeper} (and any future packages that generate
+  R code from API specs, or, eventually, API specs from R code).
+- [{anyapi}](https://anyapi.api2r.org) is intended to aid in the
+  discovery of APIs. Eventually it may also auto-generate functions to
+  interact with a newly discovered API, but that functionality is not
+  yet implemented.
+
 ## Why “beekeeper”?
 
 A beekeeper is someone who tends to bees, and {beekeeper} is a package