Just had a discussion with Craig about this. Given this is not fixable, I am +1 with having a 0.12.1 release. We somehow need to explain why 0.12 isn't there on our download page and remind people not to use this tag.
On Mon, Dec 13, 2021 at 4:54 PM Craig Condit <[email protected]> wrote: > 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] > >
