+1. I also think we need to have a discussion on how to handle RC builds in the
future given the existence of sum.golang.org <http://sum.golang.org/>.
Some possible approaches (using 1.0.0 as an example version):
1) Re-tag everything on rc build, and just ship RCs as 1.0.0, 1.0.1, 1.0.2, etc.
Pro: Reproducible builds
Con: Users may be confused about the stability of any given build.
2) Tag builds with 1.0.0-rc0, 1.0.0-rc1, etc. Once voting completes, re-tag
each component as 1.0.0 (but do NOT update go.mod/go.sum, since the binaries
cannot be changed per Apache policy).
Pro: Reproducible, still provides “final” tag for end user use
Con: Builds will contain references to -rc{x} dependencies
3) Same as #2, but use a build number scheme (1.0.0-1, 1.0.0-2, etc.), and then
re-tag as 1.0.0 after release.
Pro: Reproducible, still providing final tag for end user use
Con: Technically, these are still considered pre-release versions according to
https://semver.org/ <https://semver.org/>
I don’t see a perfect solution, but #3 seems the least bad to me.
Thoughts?
> On Dec 13, 2021, at 6:13 PM, Chaoran Yu <[email protected]> wrote:
>
> Hi all,
>
> I’m suggesting to rename the 0.12.0 release to 0.12.1.
>
> Last week we had a release candidate for 0.12.0 that had issues and didn’t
> pass the voting process. Now thanks to Craig Condit who promptly resolved all
> the blockers, we are ready to start the release process again. Due to
> YUNIKORN-896 <https://issues.apache.org/jira/browse/YUNIKORN-896> that was
> done last week, v0.12.0 was a tag that was already used in the core repo. To
> resolve a blocker, a commit was rolled back from the core’s branch-0.12
> branch. Now the core repo needs to be re-tagged and then the shim needs to
> point to the updated tag in the core. But due to a design decision
> <https://github.com/golang/go/issues/33969#issuecomment-527536161> in the Go
> Modules system (again thanks to Craig who found it), the go.sum checksum
> records can’t be updated to point to a new commit that re-uses a previous
> tag. The consequence is that we can’t re-tag the core with v0.12.0 anymore.
> This is the reason why I’m proposing the rename the upcoming release 0.12.1.
>
> Let me know if you have any concerns or other suggestions.
>
> Thanks,
> Chaoran
>
>
