Add changelog generator #296
Conversation
|
Here's what a generated NEWS.md would look like (made by me locally), except "Version" will be replaced with "azuremlsdk" |
|
|
||
| * If there have been breaking changes since the last tag, it will increment the 1st (major) version digit by 1 and set the 2nd (minor) and 3rd (patch) to 0. (e.g. 0.6.8 → 1.0.0) | ||
| * If there have been no breaking changes, but there have been feature additions, it will increment the minor digit by 1 and set the patch digit to 0. (e.g. 0.6.8 → 0.7.0) | ||
| * If there have been no breaking changes nor feature additions, but there have been bug fixes, it will increment the patch digit by 1. (e.g. 0.6.8 → 0.6.9) |
There was a problem hiding this comment.
I thought we wanted to align part of the version to the Python SDK version that we use right?
There was a problem hiding this comment.
Maybe? I remember Paul asking for semantic versioning during our meeting. The issue would then be replacing the logic for generating a version # with whatever scheme the Python SDK is using - which won't really match since not all of our of breaking changes = a Python SDK breaking change. I'm not sure how we align with the Python SDK numbers while maintaining semantic versioning vis a vis our own changes.
There was a problem hiding this comment.
Let's keep the patch and minor version increments as you have here. For major version can we just keep it at 0 for now?
|
|
||
| The generator follows semantic versioning, so: | ||
|
|
||
| * If there have been breaking changes since the last tag, it will increment the 1st (major) version digit by 1 and set the 2nd (minor) and 3rd (patch) to 0. (e.g. 0.6.8 → 1.0.0) |
There was a problem hiding this comment.
It is likely that we will have some breaking changes while we are still in preview, but where we do not yet want to increment the major release to 1.0
There was a problem hiding this comment.
how do you want to handle those? We could create another tag prefix specifically for this, but which digit should we increment and how?
There was a problem hiding this comment.
is it possible to just not increment the major version?
There was a problem hiding this comment.
What if we do this: until we do a major release, we keep the major at 0, use minor to indicate breaking changes, and use the two digits of patch to indicate new features and patches.
e.g.
breaking change: 0.6.85 --> 0.7.00
new feature: 0.6.85 --> 0.6.90
patch: 0.6.85 --> 0.6.86
Then, once we do our release, we can do 1.0.0 and do traditional semantic versioning from then on.
@heemanshusuri for his thoughts
|
|
||
| If the PR does not begin with one of these prefixes, it WILL NOT be included in | ||
| the release notes, so make sure to name important PRs accordingly. | ||
|
|
There was a problem hiding this comment.
@diondrapeck should we add a prefix for documentation?
There was a problem hiding this comment.
good point - i'll add a "documentation: " tag that won't affect the version number.
No description provided.