search

capistrano / sshkit

A toolkit for deploying code and assets to servers in a repeatable, testable, reliable way.
MIT License
1.16k stars 255 forks source link

Add chandler to release process? #291

Closed mattbrictson closed 9 years ago

mattbrictson commented 9 years ago

@leehambley You mentioned perhaps doing a release of SSHKit this week. Would you be open to adding chandler to the release process? I can open a PR for it.

Basically chandler automatically inserts CHANGELOG entries into GitHub's releases page when you rake release the gem. It improves the project documentation and also makes release notes available to third-party tools like Sibbell.

Thoughts?

leehambley commented 9 years ago

@mattbrictson I see that chandler is your own project, but I rather think a manually maintained changelog is better than machine generated, and I don't think anyone really uses the Github releases page, we don't have binaries uploaded there, and I can't imagine in the face of a curated changelog file that it's very useful to have the git log summarized there. (I always compare two tags, if I care)

That all said, I might have my head under a rock, Sibbell was also new to me, and I'm not sure about that. We tried to support a community drive with CodersClan, and it was an waste of time - so I'm not sure about supporting arbitrary community stuff again on the side.

We already maintain a CHANGELOG, do we need another in another format, or is what we do now arguably worse than machine generated? I prefer the curated one, since people are usually writing horrible commit messaged ":rocket: fixed a thing", and whist personally I believe in writing commit messages in a way that you generate a useful changelog automatically, but it's in conflict with asking people to force-push already reviewed branches, and/or build a consistent history in the branches before we FF merge them… I dunno mate :)

mattbrictson commented 9 years ago

@leehambley I understand your hesitation, and I don't want to push chandler too hard. But it requires no change to the CHANGELOG format or to the current process. It is just a script that parses the existing CHANGELOG and uploads that text into the GitHub releases. (It doesn't use git logs.)

Admittedly, this results in the identical release notes in two places: one copy in the CHANGELOG, and another copy in GitHub releases, but the CHANGELOG is still the authoritative source and the one we edit in PRs, etc. The latter is maintained automatically by the chandler script.

Anyway, that's my pitch!

leehambley commented 9 years ago

Sold, I imagined it would based on the git log from the last tag to this one. Be my guest and send a PR. Cheers.

mattbrictson commented 9 years ago

Closed in favor of PR #292