You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changelog Entries are great, but ultimately you're going to want to provide your users with full-on release notes.
Following the idea that the ticket should be the central thing that ties together all the aspects of the related work, then the ticket should contain the release notes.
You only want release notes for the features that went out in a release. As our Changelog entries contain a pointer back to the ticket, the generation of the CHANGELOG.md should be able to pull in the release notes.
Base Assumption
In most ticketing systems the contributors to the project have the ability to edit the description of the ticket. Observers may be able to comment, but only contributors can edit the description.
Proposed Changes
Extracting Release Notes From tickets
Going with the Base Assumption above. Users would be able to add a section to the ticket's description that started with a "RELEASE NOTES" header, and was followed by the release notes. This would be done at the bottom of the ticket, and be followed by the actual release notes (in Markdown format). There must be at least one # before "RELEASE NOTES"
## RELEASE NOTES
This feature is spectacular and will change your life for the better.
Your babies will grow up big and strong, and your car will never be dirty.
The changelog generator would utilize the ticket information (id or link whatever is appropriate for the type of ticketing system used) and extract this information and include it in the CHANGELOG.md (see below).
Links in Entries
Links to ticket numbers in entries should be optional, and probably unnecessary when release notes are present. See Issue #16
Including Release Notes in the CHANGELOG.md
When a Release Note is found within a ticket (see above) the contents of that Release Note should be included as an item in a sublist. CSS can handle styling this as desired. For example, if the release notes are the same as shown above...
Changelog Entry Description:
Added a random "boop" sound.
Generated CHANGELOG.md
...
## Added
* Added a random "boop" sound
* This feature is spectacular and will change your life for the better.
Your babies will grow up big and strong, and your car will never be dirty.
* Added some other feature with no release notes. Sad Feature. :(
...
Methodology
We have a number of potential complications to deal with when implementing this functionality:
Most ticketing systems require some some sort of authentication to allow access to a specific ticket's details. We obviously won't have everyone's keys. ;)
The generation of the CHANGELOG.md will frequently be part of the deployment process, and everyone handles that a little bit differently. We can't assume the location of the auth key. We can't even assume that a single string token is enough to grant access to a system.
@masukomi doesn't have the time to write tools for integrating with every ticketing system out there.
Thus, we need a way to allow users to create tools that can use the ticket information in the changelog entry to extract release notes from the ticketing system.
To accomplish this we will add a new (optional) key to the config release_notes_generator this will be the name of or path to an executable that changelog_manager can execute when generating the CHANGELOG.md file. CM will pass that executable the ticket number, and the link (if available). It expects a markdown string in response. CM will handle indenting that string as appropriate for insertion into the sublist. If the release notes generator is unable to find any release notes for that entry it should exit with a status of 1. E.g. exit 1 If it encounters any other problem it should exit with a different non-zero exit status. E.g. exit 2 Success, should obviously exit with 0
Upon successfully receiving a some release notes from the specified release notes generator CM would indent it appropriately and give it a bullet such that it would be shown as an entry in a unordered list under the changelog entry.
The text was updated successfully, but these errors were encountered:
Changelog Entries are great, but ultimately you're going to want to provide your users with full-on release notes.
Following the idea that the ticket should be the central thing that ties together all the aspects of the related work, then the ticket should contain the release notes.
You only want release notes for the features that went out in a release. As our Changelog entries contain a pointer back to the ticket, the generation of the
CHANGELOG.md
should be able to pull in the release notes.Base Assumption
In most ticketing systems the contributors to the project have the ability to edit the description of the ticket. Observers may be able to comment, but only contributors can edit the description.
Proposed Changes
Extracting Release Notes From tickets
Going with the Base Assumption above. Users would be able to add a section to the ticket's description that started with a "RELEASE NOTES" header, and was followed by the release notes. This would be done at the bottom of the ticket, and be followed by the actual release notes (in Markdown format). There must be at least one
#
before "RELEASE NOTES"The changelog generator would utilize the ticket information (id or link whatever is appropriate for the type of ticketing system used) and extract this information and include it in the CHANGELOG.md (see below).
Links in Entries
Links to ticket numbers in entries should be optional, and probably unnecessary when release notes are present. See Issue #16
Including Release Notes in the CHANGELOG.md
When a Release Note is found within a ticket (see above) the contents of that Release Note should be included as an item in a sublist. CSS can handle styling this as desired. For example, if the release notes are the same as shown above...
Changelog Entry Description:
Generated CHANGELOG.md
Methodology
We have a number of potential complications to deal with when implementing this functionality:
Thus, we need a way to allow users to create tools that can use the ticket information in the changelog entry to extract release notes from the ticketing system.
To accomplish this we will add a new (optional) key to the config
release_notes_generator
this will be the name of or path to an executable thatchangelog_manager
can execute when generating the CHANGELOG.md file. CM will pass that executable the ticket number, and the link (if available). It expects a markdown string in response. CM will handle indenting that string as appropriate for insertion into the sublist. If the release notes generator is unable to find any release notes for that entry it should exit with a status of1
. E.g.exit 1
If it encounters any other problem it should exit with a different non-zero exit status. E.g.exit 2
Success, should obviously exit with0
For example:
Upon successfully receiving a some release notes from the specified release notes generator CM would indent it appropriately and give it a bullet such that it would be shown as an entry in a unordered list under the changelog entry.
The text was updated successfully, but these errors were encountered: