Document release procedure

[mabruzzo]

This is intended to resolve #185.

This PR adds documentation describing the release procedure. While I was writing this up, I also described our versioning policy. In the discussion of our versioning policy, I drew a lot of comparisons with Semantic Versioning (since that seems to be arguably the most popular schemes in non-python projects).

Everything I wrote up is based on historical precedent.

Please let me know if you dislike how things are worded, if you disagree with anything I said, or if I'm missing things.

[mabruzzo]

I made a bunch of tweaks based off of your comments (thanks I think they have improved things quite a lot!).

I made 2 other changes:

• I expanded on what usually goes into Release notes
• I broke the step of updating the version numbers into 2 (first we update to the release number and then we update to the next dev version).
  • Originally, the procedure suggested doing this as one step, but I could easily imagine accidentally tagging the wrong thing with the release.
  • For example, I could easily imagine drafting the Release Notes with the main-branch target and forgetting to update the release target to the precise commit where we have updated the version number stored in the repository (or even if I remembered, I could imagine picking the wrong commit).
  • It seems less error-prone to make a separate PR to do this (plus I think it's closer to what we already do).

Let me know what you think of these updates!

Also, let me know what you think of my idea of always having the dev-version always correspond to the next micro-release number

[brittonsmith]

• I broke the step of updating the version numbers into 2 (first we update to the release number and then we update to the next dev version).

I agree, this is probably simpler and also easier to review as a PR. That said, releases through github are undoable, so it's not the end of the world if we mess it up. If we add automatically uploading to pypi of pygrackle, then we would need to be more careful.

All that said, I still see it here as happening in one step as commit A and commit B. Did you mean to change this to issuing two separate PRs?

[mabruzzo]

• I broke the step of updating the version numbers into 2 (first we update to the release number and then we update to the next dev version).

I agree, this is probably simpler and also easier to review as a PR. That said, releases through github are undoable, so it's not the end of the world if we mess it up. If we add automatically uploading to pypi of pygrackle, then we would need to be more careful.

Gotcha. I didn't know it wasn't reversible.

All that said, I still see it here as happening in one step as commit A and commit B. Did you mean to change this to issuing two separate PRs?

Oops, I partially made that change, but I seemed to have gotten distracted. It should be fixed now

I also added a description of the new development-versioning strategy. As I mentioned before, I didn't feel particularly strongly about the .dev<N> vs. -dev suffix and would be content either way. But, since we are changing strategies, I figured that changing suffixes might be a nice way to help visually distinguish the version numbers.