Update maintenance.md with more details on releases

MAINTENANCE.md

@@ -7,30 +7,53 @@ It's a work in progress so expect it to change and, hopefully, get better and mo
 
 ## Releases
 
-### When to release?
+### Why release
+
+So users can use new features. Ideally, no one is installing from source, i.e., `remotes::install_github("nceas/arcticdatautils")`.
+
+### When to release
 
 Whenever, really.
-Since this package isn't on CRAN, we can release it as much as we like and we're only bothering people we know and those people can tell us how displeased they are with how often we're releasing this package in person.
+Since this package isn't on CRAN, you can release it as much as you like or need to.
+You might want to release either when:
+
+- You accrue enough changes to write an interest release announcement ("Hey, look at his cool new release that fixes annoying bug X!")
+- You accrue at least one change and users of the package need the fix immediately
+
+### How to release
 
-### How to release?
+There are a few steps in releasing a new version of the package:
 
-- Increment the `Version` tag in the `DESCRIPTION` file to the appropriate next version.
+1. Increment the `Version` tag in the `DESCRIPTION` file to the appropriate next version.
+
+  What this is set to specifies what the user sees from R when they run `sessionInfo()` or `devtools::session_info()` and tell you what version they have installed.
 
   This package tries to use [Semantic Versioning](https://semver.org/) (semver) which can be summarized in three bullets:
-  
+
   > Given a version number MAJOR.MINOR.PATCH, increment the:
   >
   > - MAJOR version when you make incompatible API changes,
   > - MINOR version when you add functionality in a backwards-compatible manner, and
   > - PATCH version when you make backwards-compatible bug fixes.
-  
+
   Note: A common mistake people make is thinking that the next version after 0.9 is 1.0, but it could be 0.10, then 0.11, and so on.
 
-- Make and push a commit with just that diff.
+  `git` and GitHub helps us a lot with determining _what_ has changed so we can determine what the next release version number should be. We can compare a previous release to `master` to get a list of all commits what were made between that release and now:
 
-  Example here: https://github.com/NCEAS/arcticdatautils/commit/87f91179f4820ecdb283672e2179984d4f6cd334
+  > https://github.com/NCEAS/arcticdatautils/compare/v0.6.3...master
 
-- Go to [the releases tab](https://github.com/NCEAS/arcticdatautils/releases) and click "Draft a new release"
+
+- Make and push a commit with just that diff,
+
+  ```sh
+  git add DESCRIPTION
+  git commit -m "vx.y.z"
+  git push
+  ```
+
+  [Example here](https://github.com/NCEAS/arcticdatautils/commit/87f91179f4820ecdb283672e2179984d4f6cd334).
+
+2. Go to [the releases tab](https://github.com/NCEAS/arcticdatautils/releases) and click "Draft a new release"
 
   - Tag version and Release title should match v{MAJOR}.{MINOR}.{PATCH}, e.g., v6.4.5
   - The release description should include:
@@ -39,7 +62,15 @@ Since this package isn't on CRAN, we can release it as much as we like and we're
 
       Example: https://github.com/NCEAS/arcticdatautils/releases/tag/v0.6.2
 
-- You're done, now go tell people to upgrade!
+  - Make liberal use of GitHub's Compare feature: [Example](https://github.com/NCEAS/arcticdatautils/compare/v0.6.3...master) comparing `v0.6.3` to `master`.
+
+You're done, now go tell people to upgrade!
+
+```r
+remotes::install_github("nceas/arcticdatautils@*release")
+```
+
+Note: `@*release` specifies that the latest release should be installed.
 
 ## Pull Requests