search

crate-ci / git-conventional

Conventional Commit API
docs.rs/git-conventional
Apache License 2.0
28 stars 7 forks source link

fix: return-values of `Commit::footers()` and `Commit::breaking_description()` use lifetime of message… #16

Closed Byron closed 3 years ago

Byron commented 3 years ago

…instead of the one of self of the parsed structure, which allows these return values to stay alive even after Commit perished.

epage commented 3 years ago

New release out with this fix.

Byron commented 3 years ago

Awesome, thanks a lot!

I noticed that now that smart-release can make releases easy, the most difficult thing to do consistently is to produce decent changelogs. There I envision a non-destructive tool that can merge information from the commit history into the respective changelog, none-destructively, allowing the user to write their own even based on the initial version created by the tool. A possible workflow would be to run cargo changelog once to update the changelogs related to an impending release, edit them manually until they are nice, keeping the 'unreleased' title, followed by cargo smart-release to update this title to the actual version number that it then can choose itself if not specified.

Further down the road, this would enable dumping the changelog of the current release into the release tag object, and even run gh releases create to have that picked up by github to create nice release notifications.

With all that in place, making high-quality releases of complex workspaces should finally be achieved.

epage commented 3 years ago

I feel like your post needs to end with maniacal laughter :)

Personally, I like my release to be made in my CI in response to my tag. This keeps the hosting system agnostic to the language release process. I use release-notes.py in a CI job to create my release.

btw if you want to use Conventional to help with releases, try out committed to encourage use of it.

As I said before, I go back and forth on release notes. I'm not anti-automated, something is better than nothing. Adoption of Conventional hasn't been great and I dislike dealing with merge-conflicts in CHANGELOGs. Also, once you get to workspaces, it becomes unclear which crate the message applies to when dealing with multi-crate changes. One idea is to have a Github Action to auto-submit a changelog fragment which you can manually review and cleanup before release.

Byron commented 3 years ago

I feel like your post needs to end with maniacal laughter :)

😆

Personally, I like my release to be made in my CI in response to my tag. This keeps the hosting system agnostic to the language release process. I use release-notes.py in a CI job to create my release.

Thanks for sharing - I think ultimately that's also what I will do at least for gitoxide. CI would probably pull the changes from the tag object and write it directly into the release. Apparently GitHub does that automatically (?) or can be told to do that, so it shouldn't be too hard either way. Then again, if gh is available, it seems so much easier to trigger this locally. Let's see. (Yes, 180° turn of opinion in one paragraph, pure madness).

btw if you want to use Conventional to help with releases, try out committed to encourage use of it.

I saw it, but also know I will be the worst offender. Having tried 'conventional' before I know I only want to use it for changelog generation, while most of the commits will just document those tiny steps during development.

As I said before, I go back and forth on release notes. I'm not anti-automated, something is better than nothing.

I couldn't agree more, manual editing is required for awesome changelogs. However, I think there should be a way to generate a frame for the user to fill in and auto-update titles during release. This should be the best of both worlds then.

Adoption of Conventional hasn't been great and I dislike dealing with merge-conflicts in CHANGELOGs.

My plan is to only deal with changelogs before release, pulling the relevant messages from the commit history.

Also, once you get to workspaces, it becomes unclear which crate the message applies to when dealing with multi-crate changes. One idea is to have a Github Action to auto-submit a changelog fragment which you can manually review and cleanup before release.

Absolutely - sometimes a crate used by others changes, and there is a commit spanning multiple crates. This potentially makes the commit appear in multiple changelogs, and it's the user to to decide what to do with it. I plan to have a mechanism to identify all entries in a changelog and add hidden (but parsable) remarks to allow hiding them. That way, next time the changelog is generated the hidden ones won't re-appear. The same mechanism can be used to change entries, i.e. improve their wording or add details.

Thanks for git-conventional btw., I think it's very well done and saved me a lot of time. On a whim I felt it would be nice to have it parse bytes just because the unspecified (but assumed to be UTF-8) git commit encoding, so it's certainly fair to use str instead. Who knows, maybe the possible legacy encodings would make markers like : impossible to find anyway and it's better to try converting it to UTF-8 when encountered.