Prepare for 1.0.1 release #2296
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brendandburns, cjihrig The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/do-not-merge |
|
/hold |
|
It just occurred to me, this should be v1.1.0 because we have new APIs in #2275. |
|
do we want to make a 1.1.0-rc1 if we are bumping minor version to get some feedback as we have a couple issues open around the middleware/ header patching that this should resolve? Not blocking, feel free to skip |
|
An "rc" might be a good idea due to the shear size of #2275, but I don't feel strongly one way or the other. |
|
@cjihrig can you clarify? I looked at that PR, I see new (fixed?) behavior, but no new APIs and no breaking changes. I feel like this is sufficient to mark as a patch release, not a minor version, but I'm open to discussion. |
|
I was referring to |
|
Given that they are additive, I wouldn't consider it a breaking change (which is typically my bar for minor vs patch) |
|
Personally, I don't feel a strong need for RC, since people can always revert back to 1.0.0 if they encounter problems. Also most of the changes in that PR are identical changes, just in lots of different files. Ultimately we should probably move to a branch and cherry-pick model instead of release from head, that would also give better explanations of what changed. |
I see- by that bar it definitely isn't a breaking change and is fully backwards compatible, so the rc isn't necessary |
OK. I was going by semver. But if this repo doesn't use semver, then 1.0.1 is fine. /unhold |
|
@cjihrig I re-read the semver spec and you're right. It's probably worth following semver, I'll send another PR. |
cc @cjihrig
Related to #2160