Skip to content

workflow: add PR types explanation #475

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 9 commits into from
Apr 30, 2018
Merged

workflow: add PR types explanation #475

Changes from 6 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
320366e
workflow: add PR types explanation
0xc0170 Mar 27, 2018
30593d0
workflow: fix feature release naming
0xc0170 Apr 3, 2018
22f58a7
workflow: add versioning
0xc0170 Apr 3, 2018
064ca05
workflow: fix wording for bugfix anf feature
0xc0170 Apr 3, 2018
374b84b
workflow: fix line brake, fix too detailed
0xc0170 Apr 4, 2018
9bc8147
workflow: breaking change to be in major
0xc0170 Apr 4, 2018
0ee5d09
Copy edit workflow.md
Apr 11, 2018
c39403e
workflow: use release version document reference
0xc0170 Apr 13, 2018
a6ba0af
Change passive to active voice in workflow.md
Apr 13, 2018
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
46 changes: 45 additions & 1 deletion docs/reference/contributing/guidelines/workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,14 @@ Pull requests on GitHub have to meet the following requirements to keep the code
- Avoid merging commmits. (Always rebase when possible.)
- Pull requests should fix a bug, add a feature or refactor.

#### Mbed OS release versioning

Version number MAJOR.FEATURE.PATCH where:

- MAJOR version for incompatible API changes
- FEATURE version for adding functionality in backward-compatible manner
Copy link
Contributor

Choose a reason for hiding this comment

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

Interesting. So we're abandoning the MINOR release terminology?

Copy link
Contributor

Choose a reason for hiding this comment

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

"functionality in backward-compatible manner" to "functionality in a backwards-compatible manner"

Copy link
Contributor Author

@0xc0170 0xc0170 Apr 4, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Yes, we have feature releases.

language will fix (waiting for Amanda to guidance)

Copy link
Contributor

Choose a reason for hiding this comment

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

Marketing strikes again!

Copy link
Contributor

@theotherjimmy theotherjimmy Apr 5, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

One of my least favorite "we renamed a standard thing" instances.

- PATCH version for backward-compatible bug fixes

### Pull request categories

#### Bug fixes
Expand All @@ -80,7 +88,43 @@ Each feature has a tech lead. This person is responsible for:
- Rebasing often to track master development.
- Reviewing any addition to the feature branch (approval required by the feature tech lead or another assigned person).

#### Pull request template
##### Pull request types

We consider the following pull request types.

##### Fix

A bug fix is backward-compatible internal change that fixes incorrect behavior.

Release: patch

##### Refactor

Refactors are intended for feature releases if they are not fixing specific issue as they can introduce new issues.

Release: feature

##### New target

Adding a new target targets the patch release as it updating targets folder implementation.

Release: patch

##### Feature

New features targets feature releases. It can be integrated only if the feature supports most of the targets (if it requires new target HAL implementation).

Adding a new functionality is considered to be a feature. It does not matter if it is C++, C or Python.
Copy link
Contributor

Choose a reason for hiding this comment

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

👍


Release: feature

##### Breaking change

Any change that results in breaking user space. It should have strong justification to be considered. Often the change could be made backward compatible, for example deprecate the old functionality and introduce the new replacement.
Copy link
Contributor Author

@0xc0170 0xc0170 Apr 5, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

@SenRamakri asked good question. As this is quite serious type of pull request, we might want to clarify more.

Shall I add breaking user space (an application requires changes to continue working) or similar. This also leads to another good question is - what can actually break (what is considered public vs internal) ? It might be good to answer this via separate PR. So lets stick here for what is breaking change and how to make it clear to users.


Release: major

##### Pull request template

Below is a good example of a pull request:

Expand Down