Now that we have reached a consensus, I’ll go ahead with a 0.12.1 release. I’ve created YUNIKORN-980 <https://issues.apache.org/jira/browse/YUNIKORN-980> to track release process improvement that will be used for 1.0.0. When I make the website changes to announce 0.12.1, I’ll briefly explain the reason we skipped 0.12.0
> On Dec 13, 2021, at 17:20, Weiwei Yang <[email protected]> wrote: > > 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] >> >>
