Add basic instructions for cutting a new release (#369)

Since making a release is kind of a nightmare right now, it's probably
worth writing down what order packages have to be updated in. Long-term
we should try to automate this but until then, a stopgap is to put
instructions in the README

README.md

@@ -120,5 +120,22 @@ This project has unveiled a handful of interesting bugs and quirks in Roblox!
 - `Color3` properties not serialized as `Color3uint8` would have their colors mistakenly clamped in the XML place format. This was bad for properties on `Lighting`.
 - `ColorSequence`'s XML serialization contains an extra value per keypoint that was intended to be used as an envelope value, but was never implemented.
 
+## For Maintainers
+
+Cutting new releases is not currently as optimized as it should be. While we work on improving it, packages need to be published in a specific order to make sense. The order that currently works well is:
+
+1. `rbx_types`
+2. `rbx_dom_weak` and `rbx_reflection`
+3. `rbx_reflection_database`
+4. `rbx_binary` and `rbx_xml`
+
+The process for publishing these is:
+
+1. Decide a new version number, following [SemVer](semver.org/)
+2. Update changelog to list new release under its own heading
+3. Increment version in `Cargo.toml`
+4. Add a git tag in the format `library_name-vMAJOR.MINOR.PATCH` at the commit that incremented the Cargo version
+5. Publish to Cargo
+
 ## License
 rbx-dom is available under the MIT license. See [LICENSE.txt](LICENSE.txt) for details.