Release the operator v0.111.0

[mx-psi]

No description provided.

[frzifus]

Blocked by:

• Use 0.0.0.0 as otlp receiver default address #3126
• Remove ComponentUseLocalHostAsDefaultHost() #3306

[pavolloffay]

@swiatekm you seem to be next on the list https://github.com/open-telemetry/opentelemetry-operator/blob/main/RELEASE.md#release-schedule

[swiatekm]

We still haven't released 0.110.0, and we can't until the issues linked by @frzifus are resolved.

[frzifus]

Working on it to get it resolved by the end of today.

[frzifus]

PR: #3334

cc @swiatekm

[mx-psi]

I think this is unblocked now, right?

[frzifus]

Yes, i will start working on it tomorrow morning

[pavolloffay]

I would like to get this #3338 in the release

[frzifus]

I would like to get this #3338 in the release

Y, that shoudlnt be an issue. I would like to get #2801 in too. 😄

[frzifus]

Do we miss something else in this release @open-telemetry/operator-approvers or should we rebase #3351 and cut v0.111.0?

[swiatekm]

Should we upgrade the collector version immediately when it's released, rather than when releasing operator? It's not ideal to only find out about any breaking changes that affect us when we create the release PR. WDYT?

[frzifus]

mh.. Does this cause problems if you manage your own operator build with custom images?

[swiatekm]

mh.. Does this cause problems if you manage your own operator build with custom images?

I don't think so? The changes are the same, they just happen at a different time. Right now, we update all the versions at once; with my proposal, we'd update the collector version, and then create the release PR a ~week later.

[jaronoff97]

I think it would make our compatibility guarantees a bit more challenging though, especially if we're going to introduce something to assist with a breaking change via our upgrade webhooks...

Oh wait are you proposing just bumping the collector version and then we release the operator when we're confident in its functions? I like that.