Skip to content
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.

Sign up for GitHub

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

Jump to bottom

v1.0.0 Changelog scratchpad #417

Closed
mrpollo opened this issue Jun 5, 2018 · 6 comments
Closed

v1.0.0 Changelog scratchpad #417

mrpollo opened this issue Jun 5, 2018 · 6 comments

Comments

@mrpollo
Copy link
Member

mrpollo commented Jun 5, 2018 •
edited by AuterionWrikeBot
Loading

Hey everyone I generated the following changelog, can we please review?

Change Log

v1.0.0 (2018-06-04)

Full Changelog

Closed issues:

  • Add documentation for methods in device.h #296

Merged pull requests:

v0.5.0 (2018-06-04)

Full Changelog

Implemented enhancements:

  • Python bindings for the core library #388
  • Examples should use consistent connection startup semantics #380
  • Implement mission features in backend #350

Fixed bugs:

  • transition_vtol_fixed_wing example never ready to arm #401
  • fly_qgc_mission error loading shared libraries: libjson11.so #381
  • Mission subscribe blocked by mission pause #373
  • Random crash in Yuneec SDK #309

Closed issues:

  • fly_mission and fly_qgc_mission examples freezes on mission accepted #399
  • [Help] How to use DroneCore in HITL Gazebo #355
  • Implement remaining actions in backend #315

Merged pull requests:

v0.4.0 (2018-04-26)

Full Changelog

Implemented enhancements:

  • Rename "Mavlink" stuffs to that of "MAVLink" #329
  • Support for COMMAND\_INT #326
  • Return vectors by value in C++11 #319
  • Class name change: Device to System #318
  • Choosing reference over pointer #314
  • Add support to include Doxygen tags \code and \endcode #259
  • Rename camera\_action\_delay\_s to loiter\_time\_s in MissionItem class #249
  • Connection URL for DroneCore applications #244
  • FollowMeImpl::set_config() returns immediately though Device didn't confirm #221
  • Cross-compile the backend for iOS #213
  • Cross-compile the backend for Android #212
  • Have one gRPC server library for each plugin #211
  • Dynamically load plugins in dronecore_server #210
  • device.h should become a library #209
  • Build core as a library #208
  • Build each plugin in its own library #207
  • Clarify FollowMe::Config::min_height_m and follow_dist_m #204
  • Exposing Flight mode APIs in core/device_impl.h #193
  • FollowMe API feels inconsistent #191
  • Follow Me has no example #189
  • Add public API to control camera outside of missions #154
  • Add Gimbal telemetry #141
  • Implement mavlink camera definition #126
  • Dynamic plug-in infrastructure #106
  • gRPC: APIs expose through gRPC #95
  • Improvements to core #359 (shakthi-prashanth-m)
  • Make use of smart pointers and references #316 (shakthi-prashanth-m)
  • Add Follow me example #217 (shakthi-prashanth-m)

Fixed bugs:

  • Mission items are not cleared before building them up #348
  • DroneCore application (GCS) should NOT mix up with System/Device #317
  • Takeoff example exits before vehicle is ready #307
  • Autoupilot type used for GCS is wrong #305
  • Script generate_docs.sh doesn't identify whether build directory is empty #236
  • Running integration tests with AUTOSTART\_SITL=1 fails #227
  • Device never gets connected again after heartbeat timed out #214
  • TCP connection drop causes high CPU usage #201

Closed issues:

  • Problems connecting to multiple PX4s in SITL #353
  • [Mission]Set speed function is not available #341
  • Implement telemetry health in backend #333
  • Implement frontend core #332
  • Maintain a connection instance per component in case of UDP #331
  • Run Takeoff Example Fail #301
  • Compile backend to a Framework on iOS #294
  • Camera plugin to implement MAVLink Camera Protocol client interface #292
  • Example for installing the DroneCore on Raspberrypi #284
  • Missing sample plan for example #272
  • Update backend to new core proto #269
  • Update backend to new mission proto file #268
  • Update backend to new telemetry proto file #267
  • Can't build docs #245
  • Update dronecore_server to use newly-defined action protocol #238
  • Flight testing DroneCore examples on Intel Aero #233
  • Unable to establish serial connection to PC #231
  • Error during make default #226

Merged pull requests:

* This Change Log was automatically generated by github_changelog_generator
@julianoes
Copy link
Collaborator

@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.

@hamishwillee
Copy link
Collaborator

hamishwillee commented Jun 5, 2018 •
edited
Loading

@julianoes The docs release happen after the fact, but should match your releases: https://github.com/dronecore/sdk_docs/releases
At the top of those notes is a link to associated docs. It might be worth creating just that link to the online version of the docs in the software release notes (?)

@anitha-suresh-zz
Copy link

@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

@JonasVautherin
Copy link
Collaborator

Can we please not categorize 'Fixed', 'Closed', 'Merged'.

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.

@anitha-suresh-zz
Copy link

Can we please not categorize 'Fixed', 'Closed', 'Merged' - I meant do we need all three as part of release notes.

@julianoes
Copy link
Collaborator

I'll continue doing this manually for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mrpollo @julianoes @JonasVautherin @hamishwillee @anitha-suresh-zz