Provide access to individual footer fields

[epage]

A footer of one or more lines MAY be provided one blank line after the body. The footer MUST contain meta-information about the commit, e.g., related pull-requests, reviewers, breaking changes, with one piece of meta-information per-line.

Right now, the rust parser treats the entire footer as a blob under BREAKING CHANGE.

[JeanMertz]

I'm working on this, but am really not a fan of the way this is described in the spec.

What I've got working right now is this:

feat(test): description

body
goes

here and here.

BREAKING CHANGE: Breaking change alert!

Very breaking, much bad.

Co-Authored-By: me
Co-Committed-By: you

This would create 3 Trailers with their key set to BREAKING CHANGE, Co-Authored-By and Co-Committed-By, with their respective values.

The only thing that is not valid according to the spec is this:

with one piece of meta-information per-line

I find it very unpleasant to be forced to describe a breaking change in one line. For breaking changes, I always like to be declarative, possibly adding a few small code snippets to explain how to upgrade to the latest changes.

Not sure how to tackle this yet, I'll keep this open while I continue to work on this, and perhaps I'll deviate from the spec for now, until version 1 is released, and then perhaps decide on allowing for a way to change the behaviour of the library based on a set of options (as few as possible, but this one seems very valid and useful).

[epage]

I find it very unpleasant to be forced to describe a breaking change in one line. For breaking changes, I always like to be declarative, possibly adding a few small code snippets to explain how to upgrade to the latest changes.

The spec gives the option for a one line breaking change in the footer or to use the body to describe the breaking change.

Even if that does work for you, maybe open an issue on the spec for supporting the Trailer syntax for multi-line footers?

[JeanMertz]

I've written a proposal in conventional-commits/conventionalcommits.org#179.

I'm inclined to follow that proposal as a design exercise for now, until consensus is reached, after which we either go back to following the v1 spec with an option to enable a more strict implementation, or the v1 spec incorporates (some form of) those changes and they'll be the default without any option required.

[JeanMertz]

This is implemented in bf552e5.

There are probably some edge-cases that still need some attention, but the current set of tests are passing as expected.

This doesn't follow the spec yet, as I've implemented the proposal I made for full support for Git trailers. We'll see where that proposal ends up, and decide on the next steps once v1 of the spec ships with or without trailers support.