Hi Chaoran, Craig and I have been discussing the same thing while looking at the build. Tags are considered immutable when they are created as per [1] When you look at the sum database info at [2] it is almost instant. So yes we get to a new schema. I also think that option 3 is the best option to go to in the future.
For this release I think we need to move to v0.12.1 Wilfred [1] https://github.com/golang/go/issues/33969 [2] https://sum.golang.org On Tue, 14 Dec 2021 at 11:20, Craig Condit <[email protected]> wrote: > +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 > > > > > >
