-
-
Notifications
You must be signed in to change notification settings - Fork 507
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
v1.0.0 Changelog scratchpad #417
Comments
@mrpollo that's nice to auto-generate it but I actually wrote the changelogs manually in the release notes, check out https://github.com/dronecore/DroneCore/releases. This way it's easier to read and less verbose. |
@julianoes The docs release happen after the fact, but should match your releases: https://github.com/dronecore/sdk_docs/releases |
@mrpollo looks good! As it is auto generated, it would be effortless. I agree with Julian, that it looks too verbose. Can we please not categorize 'Fixed', 'Closed', 'Merged'. In release notes, it is easier and makes sense to mention at a higher level, about what feature or functionality is enabled (as there might be some 10 items/subtasks going as part of enabling one feature/function) AND also on the major bug fixes. These are my thoughts :) Will wait for others to comment |
There is a difference between those sections, but I believe the keywords are more: 'enhancements', 'bugs', 'issues', 'pull requests'. I guess the first two come from the labels. For the last two, the thing is that some PRs are not related to an issue. If you want to simplify that, maybe we could just have 'bugs' and 'enhancements' (e.g. everything that is not labeled as a bug is an enhancement). And one question is whether we need to list both issues and PRs, or if we can keep only the PRs (because most of the time, issues are closed by PRs, but some PRs are not related to an issue). But then it means that we should make sure we put the 'bug' label on the PRs themselves. @mrpollo I like the generated report! That is neat for the "full changes" report. And at the top we should probably highlight a few features/write a high-level description of the changes. Gradle does it this way: they have some kind of blog post that says "now with gradle X.Y, you can do this, this, this and that!", then they have detailed explanations for those "key" features (sometimes linking to actual examples), and I believe they have a link to the full changelog somewhere. |
Can we please not categorize 'Fixed', 'Closed', 'Merged' - I meant do we need all three as part of release notes. |
I'll continue doing this manually for now. |
Hey everyone I generated the following changelog, can we please review?
Change Log
v1.0.0 (2018-06-04)
Full Changelog
Closed issues:
Merged pull requests:
v0.5.0 (2018-06-04)
Full Changelog
Implemented enhancements:
Fixed bugs:
Closed issues:
Merged pull requests:
v0.4.0 (2018-04-26)
Full Changelog
Implemented enhancements:
COMMAND\_INT
#326camera\_action\_delay\_s
toloiter\_time\_s
in MissionItem class #249Fixed bugs:
AUTOSTART\_SITL=1
fails #227Closed issues:
Merged pull requests:
COMMAND\_LONG
#351 (shakthi-prashanth-m)generate\_doc.sh
issue (Script generate_docs.sh doesn't identify whether build directory is empty #236) #237 (shakthi-prashanth-m)AUTOSTART_SITL=1
fails #227 #228 (shakthi-prashanth-m)* This Change Log was automatically generated by github_changelog_generator
The text was updated successfully, but these errors were encountered: