Weiwei, 0.12.0 is burned.
If a user attempts to depend on [email protected] at this point, they are now getting bits that have a critical deadlock in them, and broken code. Worse, this is invisible to them, as the GitHub tag does not reflect the same bits that they will get when compiling. We cannot use 0.12.0 any more at this point. Craig > On Dec 13, 2021, at 6:49 PM, Weiwei Yang <[email protected]> wrote: > > We should not have a 0.12.1 without a 0.12.0 release, I think that is > against the release convention. > I don't think we need to worry too much about the tags, we can tag it after > the RC passed all the votes. > Because the dependency in our release binary is locally resolved, what was > in the go mod file did not really matter that much. If you look at the tool > script here > <https://github.com/apache/incubator-yunikorn-release/blob/d689df755035a5b9f7b61bb31d5c8726f28dfd8a/tools/build-release.py#L189-L195>, > because we do a "replace" to make sure the dependencies to the (SI, core) > are pointing to the local files. > > On Mon, Dec 13, 2021 at 4:47 PM Wilfred Spiegelenburg <[email protected]> > wrote: > >> 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 >>>> >>>> >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
