-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support metadata #19
base: master
Are you sure you want to change the base?
Support metadata #19
Conversation
To clarify, in the above case, are you proposing that metadata can work in two ways:
|
I was proposing only the first way, each supported metadata must be understanded by the parser. It is possible to support the second, but in that case it means that the summary of the release must be at the top. I don't know if it's a good thing. |
Makes sense and I agree, lets see if any others have some feedback. |
I have added the missing metadata contributors, source, binaries and generated at. |
Just checking, the metadata itself is optional? Just the keys have to match for them to be recognized, right? From: Jérémie Bertrand [mailto:[email protected]] I have added the missing metadata contributors, source, binaries and generated at. — |
All metadata are optionals. |
I think the metadata should be 100% optional and that any combination of keys (if you do choose to use metadata) is possible - i.e. you can choose to use any 1 or 2. Does that match up with others thinking? |
Yep, it is done that way in the PR. |
Proposal for the support of metadata and specifically commits (Fix #14).
All metadata can be preceded by its name (case insensitive) followed by a colon, but each supported metadata have it's own syntax.
Example
For commits it's the first and last commits of the release separated by three dots and can be included in a link.
Input:
56af25a...d3fead4
Commits: [56af25a...d3fead4](https://github.com/Glimpse/Semantic-Release-Notes/compare/56af25a...d3fead4)
Result:
Html: