Release Candidate naming

[Aneurysm9]

We have a need to make a release subsequent to v1.0.0-RC1 that we do not expect will be something that could also be tagged as v1.0.0 because there are outstanding issues that need to be resolved before v1.0.0. There are two proposals for what version identifier we should use for this next release. @open-telemetry/go-approvers please comment on this discussion with your preference between the following two options:

• v1.0.0-RC2
• v1.0.0-RC1.1

Community members are free to comment with their preferences and rationale, but the consensus established among @open-telemetry/go-approvers will be binding. A release using the selected identifier will be prepared on Monday, 7/26/2021.

[jmacd]

v1.0.0-RC2 makes sense to me.

[MrAlias]

I have no preference. I support either.

[Aneurysm9]

I believe that v1.0.0-RC1.1 is most appropriate as it indicates that this release is subsequent to the first release candidate, but is not itself a new release candidate. I believe that release candidates should be tagged at commits that could be tagged without the -RC* suffix if no unknown issues arise subsequent to the release candidate.

[MrAlias]

Have we validated Go will correctly order RC1.1 < RC2?

[XSAM]

I checked codes from golang/mod, which is used by Go while comparing versions, and it can correctly order RC2 > RC1.1.

[MadVikingGod]

RC2 is my choice.

[seh]

To me, -RC2 makes more sense, but I'd like to understand @Aneurysm9's idea better. Are you saying that if we issued -RC1.1 and it held up to scrutiny, we'd then release v1.1.0, and never release a v1.0.0?

[Aneurysm9]

No, the RC1.1 component modifies v1.0.0 as a whole. It is intended to convey that it is subsequent to v1.0.0-RC1 but not a new release candidate for v1.0.0. Only a new commit that we would be comfortable tagging as v1.0.0 absent identification of unknown release blockers would be tagged as v1.0.0-RC2.

It seems that my definition of "Release Candidate" is not common. v0v

[XSAM]

I prefer v1.0.0-RC2. It seems easy to understand, yet another release candidate.

[pellared]

I prefer v1.0.0-RC2.

[dashpole]

I prefer v1.0.0-RC2

[MadVikingGod]

So I know this had a timeline of Friday, but I want to come back and put into words why my preference of -RC2 over -RC1.1 is what it is.

It comes down to simplicity.
We have already signaled with the -RC that the code is not 100% stable, otherwise, it wouldn't carry an RC, but that we are seeking review for the content. We could go full semver after the RC, but we expect a few of these so there is no point putting more meaning to a 2 than a 1.1.

I would also like to bust the myth of being able to directly release an RC as a v1.0.0. We HAVE to update the versions in the multiple go.mod files, so to have both a working RC and a working v1.0.0 they will be different.