Add info about CHANGELOG on the CONTRIBUTING #1222
Conversation
| 6. Push to the branch (`git push origin my-new-feature`) | ||
| 7. Create a new Pull Request | ||
| 5. Update [CHANGELOG.md](https://github.com/rails-api/active_model_serializers/blob/master/CHANGELOG.md) | ||
| with a brief description of your changes under the current develop version heading. |
There was a problem hiding this comment.
would love to note somehow that if there's a merge conflict with the CHANGELOG in a pr (which is frequent), the maintainers will ensure the pr is merged
There was a problem hiding this comment.
with a brief description of any breaking changes, fixes, features, or miscellaneous changes under the proper version section.
|
👍 Let's get the wording right, and then merge it. |
|
Thanks for the review. Updated with the right wording. |
| 5. Commit your changes (`git commit -am 'Add some feature'`) | ||
| 6. Push to the branch (`git push origin my-new-feature`) | ||
| 7. Create a new Pull Request | ||
| 5. Update [CHANGELOG.md](https://github.com/rails-api/active_model_serializers/blob/master/CHANGELOG.md) |
There was a problem hiding this comment.
The problem if you update the changelog at that point is that you don't know the PR reference yet.
There was a problem hiding this comment.
👍 maybe update change log and squash unnecessary commits should be done later in this process
There was a problem hiding this comment.
Usually, the following happens:
- Create your branch and commit the feature/tests, push and issue PR
- Iterate on feedback given by the community (fix syntax, modify bits of code, add tests), pushing the new commits to the PR each time
- When it looks ready to merge, update the changelog + squash the commits
|
Thanks for the review. I update the code, take a look when you have some time 😄 |
|
Nice @maurogeorge merging it. |
Add info about CHANGELOG on the CONTRIBUTING
|
Thanks for the merge 👍 |
No description provided.