Skip to content

workflow: functionality changes release notes addition #933

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

Merged
merged 7 commits into from
Feb 8, 2019
Merged

workflow: functionality changes release notes addition #933

Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
c6c56d9
workflow: functionality changes release notes addition
0xc0170 Jan 31, 2019
0003157
workflow: fix impact analysis vs description
0xc0170 Jan 31, 2019
237b127
workflow: functionality change migration fix
0xc0170 Jan 31, 2019
efc2e0b
workflow: functionality change or addition fix
0xc0170 Feb 1, 2019
f8acd99
Edit workflow.md
Feb 1, 2019
7b86eb3
workflow: impact to effects wording fix
0xc0170 Feb 5, 2019
b85177b
Add requested note to workflow.md
Feb 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/reference/contributing/guidelines/workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,13 @@ Any change in the functionality, it can be adding a new feature, adding a new me

A feature contribution contains a new API, capability or behavior. It does not break backward compatibility with existing APIs, capabilities or behaviors. New feature contributions are very welcome in Mbed OS. However, because they add capability to the codebase, it's easy for a new feature to introduce bugs and a support burden. The introduction of new features should also come with documentation, majority of targets support and comprehensive test coverage proving the correctness of the feature per the documentation. Feature PRs are treated cautiously, and new features require a new minor version for the codebase. Features are candidates for feature releases.

Every functionality change pull request must contain a release notes section called "Release notes" to describe the changes to users.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every pull request changing functionality? @AnotherButler

Copy link
Contributor Author

@0xc0170 0xc0170 Feb 1, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in efc2e0b

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should also apply for 'Breaking Changes'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this paragraph keeps the spirit of the previous ones. The first and second paragraph talks exclusively about adding new functionality. Your paragraph below talks more about changing existing functionality.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rephrased it to "Every pull request changing or adding functionality" - we want to capture additions but also changes


It must contain:
- brief description of changes introduced
- impact analysis - identify components affected, what are potential consequences for users, why do we need this
- migration guidance: before and after (good to include code snippets to illustrate)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small note: in migration guidance I suggest saying it needs to specify all the actions that the user needs to take (should be self explanatory, but still).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I rephrased it


Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a note here t hat this section will be used in official release notes ? or it's clear to reader

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, a note is useful

We initially implement new features on separate branches in the Mbed OS repository. Mbed OS maintainers create the new branches by following the naming convention: "feature-" prefix.

Each feature has a tech lead. This person is responsible for:
Expand Down