-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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.
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
chore: update changelog for release 12.0.0 #871
Merged
barryib
merged 4 commits into
terraform-aws-modules:master
from
Polyconseil:tba/new-release
May 9, 2020
Merged
Changes from 3 commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dpiddockcmp here is my proposition for this release #873
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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 😆