From 1aa7ae88906e3916ef1c0b96a0f810a1138367d2 Mon Sep 17 00:00:00 2001
From: Jon Harmon <jonthegeek@gmail.com>
Date: Fri, 26 Apr 2024 15:19:03 -0500
Subject: [PATCH] Increment version number to 0.4.0.9000 (#56)

---
 DESCRIPTION |  2 +-
 README.Rmd  |  8 ++++----
 README.md   | 12 ++++++------
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/DESCRIPTION b/DESCRIPTION
index 1abf35e..a869324 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -1,6 +1,6 @@
 Package: beekeeper
 Title: Rapidly Scaffold API Client Packages
-Version: 0.4.0
+Version: 0.4.0.9000
 Authors@R: c(
     person("Jon", "Harmon", , "jonthegeek@gmail.com", role = c("aut", "cre", "cph"),
            comment = c(ORCID = "0000-0003-4781-4346")),
diff --git a/README.Rmd b/README.Rmd
index ae80e93..05d686e 100644
--- a/README.Rmd
+++ b/README.Rmd
@@ -58,10 +58,10 @@ Most of the outline was included in the grant proposal.
     - [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.
-    -   Also add parameter type checking.
-    -   **Potential challenges:** By this point I'll need an OAS definition document to use for testing that includes all of the possible parameter types. I'll likely need to generate a fake API specification that goes beyond a typical individual example.
+- [ ] **0.5.0: More robust scaffolding.**
+    - [ ] Add parameter documentation.
+    - [ ] Also add parameter type checking.
+    - [ ] **Potential challenges:** By this point I'll need an OAS definition document to use for testing that includes all of the possible parameter types. I'll likely need to generate a fake API specification that goes beyond a typical individual example.
 -   **0.6.0: Expected results.**
     -   Add response (return value) documentation.
     -   Use expected responses to generate better test scaffolds.
diff --git a/README.md b/README.md
index 2dac121..ef66869 100644
--- a/README.md
+++ b/README.md
@@ -86,12 +86,12 @@ included in the grant proposal.
       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.
-  - Also add parameter type checking.
-  - **Potential challenges:** By this point I’ll need an OAS definition
-    document to use for testing that includes all of the possible
-    parameter types. I’ll likely need to generate a fake API
+- [ ] **0.5.0: More robust scaffolding.**
+  - [ ] Add parameter documentation.
+  - [ ] Also add parameter type checking.
+  - [ ] **Potential challenges:** By this point I’ll need an OAS
+    definition document to use for testing that includes all of the
+    possible parameter types. I’ll likely need to generate a fake API
     specification that goes beyond a typical individual example.
 - **0.6.0: Expected results.**
   - Add response (return value) documentation.