Upgrade to nginx-ingress-controller 0.28.0 #24
Conversation
CHANGELOG.md
Outdated
| @@ -5,12 +5,12 @@ All notable changes to this project will be documented in this file. | |||
| The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) | |||
| and this project's packages adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). | |||
|
|
|||
|
|
|||
| ## [v1.2.1] 2020-01-30 | |||
There was a problem hiding this comment.
| ## [v1.2.1] 2020-01-30 | |
| ## [v1.3.0] 2020-01-30 |
If we upgrade a minor version of the app, I would do the same in our chart, dont you think so?
There was a problem hiding this comment.
Sure, versions are cheap. I'd actually prefer not to have app release semantic versions at all (including platform releases) just continuously improved supported managed service. None of these changes in nginx IC 1.3.0 App are breaking backward compatibility from customer perspective so no ack from customer should be required to deploy them, as long as we do it safely. Breaking backward compatibility for a service, is a new service - these should be avoided at all costs, if still done there should be migration path if possible, but surely phase out of no longer supported version. Btw, this is not widely accepted view, just my opinion. From what I learned there will be effort invested by Ludacris into supporting continuous deployment of patch changes (hopefully it covers optional apps too) - I guess under patch it will be considered any change that's not breaking backward compatibility of the API from customer perspective, so again these 1.3.0 changes might be considered then patch level changes, but now it actually doesn't make a difference - major, minor, patch - all go through same platform release process and deployment (cluster upgrade) requires ack from or at least notification to customer.
Anyway, changed it and the release link to point to future 1.3.0 release. These release version links don't link to PR, since there are multiple included in same release.
|
I was hoping to include enabling HPA by default too in the next nginx IC App release, not because I like to cram release (and make it unsafe to deploy, incur testing costs) on contrary would like to ship every change as soon as it passes all automated pre-pord and prod checks - cramming more stuff in each release is as natural reaction to slow cumbersome platform release and delivery process, full of manual human coordination. Enabling HPA and tuning resources will have to be done in a separate release, since I'm still performing trials to find the right settings and way of configuring them, specifically dealing with variance in tenant clusters, some of the options being
|
|
@pipo02mix but you released 1.2.1 - didn't know that. Will fix changelog for 1.3.0 |
Towards https://github.com/giantswarm/giantswarm/issues/8664