chore: update changelog for release 12.0.0 #871
Conversation
|
|
||
| FEATURES: | ||
| - Create kubeconfig with non-executable permissions ([#864](https://github.com/terraform-aws-modules/terraform-aws-eks/issues/864)) | ||
| - Change EKS default version to 1.16 ([#857](https://github.com/terraform-aws-modules/terraform-aws-eks/issues/857)) |
There was a problem hiding this comment.
This is a breaking change for users who do not set cluster_version. Especially with the deprecated APIs removed in 1.16 and the fun with kubelet attributes that appeared on the PR.
It would be good to skip this feature and still release the rest as 11.2.0. I'm not sure how we'd do that with the fancy new automated changelog?
There was a problem hiding this comment.
Good point.
With the actual release process, I don't think we can do that easily once the PR is merged into master. All release come from the master branch.
If we want to do that, I think we can create a separate branch on which we'll delete the #857 commit and create a new tag from that branch.
But with that said, maybe we can just bump to 12.0.0 and start a discussion to enhance our release process. Use milestone to merge only those needed ? Use different branch for release ? etc. What do you think ?
There was a problem hiding this comment.
I can also add a section in readme and in breaking change note something like:
The default version is now 1.16. Kubernetes 1.16 includes a number of deprecated API removals, and you need to ensure your applications and add ons are updated, or workloads could fail after the upgrade is complete.
Please set explicitly your cluster version to an older EKS version untill you're ready to upgrade your workload.
There was a problem hiding this comment.
I think it would be good to modify the release process to have more point releases for non-breaking changes instead of ramping up the major version every time there is a breaking change added. For example here we're under no time pressure to release the "1.16 as default" change. Old releases still support 1.16 fine.
Breaking changes need to be documented somewhere. Previously that was the changelog and it makes sense to put them there. Can you not add custom sections to the changelog any more?
There was a problem hiding this comment.
I think it would be good to modify the release process to have more point releases for non-breaking changes instead of ramping up the major version every time there is a breaking change added. For example here we're under no time pressure to release the "1.16 as default" change. Old releases still support 1.16 fine.
Agreed. But my point was should we hold this new release until we find a proper release process or just ship this one and start working on something for the next release ?
Breaking changes need to be documented somewhere. Previously that was the changelog and it makes sense to put them there. Can you not add custom sections to the changelog any more?
Sure I can add note or breaking change note in changelog as suggested #871 (comment).
Those note should be added in the commits message and I didn't do that during the merge (squash commit). So if we agree to bump version to 12.0.0, I'll add new commit to add the breaking change note because I don't want to rewrite commits in master.
There was a problem hiding this comment.
@dpiddockcmp here is my proposition for this release #873
There was a problem hiding this comment.
There are useful changes related to managed node groups. They need releasing.
I think we're a bit limited here by what git-chglog can do.
We'd have to maintain two branches. For example:
"master" that has all the features ready for the next major release.
"release" or "v11" or whatever that has the non-breaking features and regular minor releases for the active major version.
Process:
- PRs are merged to master.
- Non-breaking changes cherry-picked in to the release branch
- Minor releases made
- Merge changelog back into master?
Issue is how to generate the changelog for the next major release? From playing around it looks like git-chglog duplicates changelog entries when they have different a SHA. So you're re-releasing all the changes made after the two branches diverge. Unless I've missed something in how to configure it?
Would we need to update the git-chglog template with the previously generated content, manually de-duplicate the major release notes, and bump the TAG_QUERY value in Makefile? Would solve the forgotten breaking changes notes 😆
barryib
changed the title
|
@dpiddockcmp ready for review. |
|
Thanks @dpiddockcmp for your help. |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
PR o'clock
Description
Prepare for release 11.2.0
Checklist