Last active
December 23, 2015 11:29
-
-
Save andreasohlund/6628660 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ReleaseNotesCompiler | |
In order to improve the quality for our release notes we'll generate them based on the relevant github issues. | |
* This is a separate tool from GFV | |
* The build server will compile the release notes either for each commit or daily | |
* Build will fail if release notes can't be generated | |
* All closed issues for a milestone will be included | |
* All issues must have one of the following tags Bug|Feature|Internal refactoring | |
* For now the text is taken from the name of the issue | |
* Milestones are named {major.minor.patch} | |
* Version is picked up from the build number (GitFlowVersion) and that info is used to find the milestone on GitHub | |
* No milestone found is considered a exception | |
* The output format should follow http://www.semanticreleasenotes.org/ | |
* We'll generate release notes as markdown for display on the website | |
* We'll generate release notes as X for inclusion in our nugets |
We should also plan to provide a grouping mechanism/component indicator.
This is definitely a separate thing from GFV.
Regarding grouping:
For us the high level grouping would be the repo level. Eg we have NServiceBus, NServiceBus.SqlServer, NServiceBus.RabbitMQ and so on. That could be done based on a convention on the repo name.
But I guess you mean components inside the same repo?
I guess Labels would be the way to do that?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is the plan for this to be intrinsically tied to GitFlowVersion? I think the two should be separate, but work well together.