1.0.0-RC3 Release - Githubissues

geotrellis / vectorpipe

Convert Vector data to VectorTiles with GeoTrellis.

https://geotrellis.github.io/vectorpipe/

Other

74 stars 20 forks source link

1.0.0-RC3 Release #78

Closed CloudNiner closed 5 years ago

CloudNiner commented 5 years ago

Have verbal 👍 from @jpolchlo in chat.

mojodna commented 5 years ago

A general request regarding releases (not that this isn't happening in part, it just happens to be a pet peeve). We should:

include a commit that contains only version-related updates (like this)
include just the version number in the commit message (in a consistent way, so it's identifiable when looking through the list of commits)
tag the commit with the version number (so that it can easily be found without looking through the list of commits)
rebase and merge (I think), to prevent a merge commit for version-only PRs (otherwise the version history can look a bit weird if the commit bumping the version is tagged vs. the merge commit being tagged)
use either a changelog file OR GitHub releases (and do so consistently)

jpolchlo commented 5 years ago

@mojodna: Can you identify which parts of this we're doing wrong? I think I might have bumped to RC2 in a non-standard way, but how Andrew did this version bump is how I would ideally do it myself. Is it a thing to have a document in the repo describing the steps for release so that we can remain consistent?

mojodna commented 5 years ago

I don't think we're doing anything wrong (@CloudNiner did it the same way I would, too); this is more of an aspirational list to potentially keep in mind.

JavaScript projects tend to be pretty consistent because npm version minor will a) update the minor version in package.json, create a commit titled `"v1.2.0" (or whatever it is), and tag that commit. Unfortunately, I don't think that works with PRs consistently.

I've seen RELEASING.md files in repos that are good reminders for how the release process works on a given project.