No process for doing releases with only changes from opentelemetry-collector-releases

[songy23]

The current release doc (https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/docs/release.md) assumes a new release must include a new version from either core collector or contrib. However if we want to do a release to fix bugs only in this repo while no change in core collector or contrib, there is no such process. The release automation workflow also assumes there to be a new version of core and/or contrib, so it cannot handle the opentelemetry-collector-releases -only release. See an example in #1070.

[dosubot]

There is currently no documented or automated process for making a release with only changes from opentelemetry-collector-releases. The release documentation and automation require that new releases of both core and contrib have already occurred before a release here, and the workflows expect version updates from those components to proceed. There are no exceptions or workarounds described in the docs or implemented in the automation to support repo-only releases, and no relevant issues or discussions proposing a solution have been found. For reference, see the release documentation and the update-version workflow.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[atoulme]

I just pushed a new tag and it triggered the release. We should document it.

[douglascamata]

We might need a way to support "rebuilds" of a given release. I seen some projects that do it like this: let's say release 1.2.3 had build issues and some artifacts are broken, they rebuild it and release as 1.2.3+001 (valid according to semver 2.0), indicating 1st rebuild.

[mowies]

Build numbers would be an option, I kinda like it. We would need to test out if goreleaser has any caveats around tags that look like that.

[mowies]

@douglascamata i looked into this a bit more. I think we could run into issue with version precedence. According to SemVer, build metadata (i.e. build number) are not considered for precedence which makes this plan non-ideal. This is especially tricky if we start with a "normal" version number, like v0.123.0 and then rebuild it with v0.123.0+1 and the old version still has precedence.
I could see us still following this build metadata pattern though as long as we document it properly, but still, I think it's not a very good experience for users.

[douglascamata]

@mowies sad but true. :(

So it seems to me like SemVer doesn't have anything that covers our case. I even found this comment where a SemVer contributor says:

In short: if the build changes anything, then it should be a new version. If it doesn't, then it is the same version with the same precedence.

Which makes me understand that according to their model, if our changes here change the release in any way, it should be a new version. 🤔

[mowies]

But usually, any changes here wouldn't actually change the release outputs at all 🤔
Think of some random release pipeline bug. After fixing the bug, the release artifacts would be exactly the same.
Same for a networking issue that prevents a container image push for example.

So that would tell me that instead of working on updating our versioning strategy, maybe it would be better to invest retry-able builds?
Or we just roll with it and treat any change in this repo as something that changes the release and move forward with incrementing the patch version.

[douglascamata]

I'd say we should do whatever is easier to automate... which I believe is the retry-able builds.