Thank you Chaoran! On Mon, Dec 13, 2021 at 5:33 PM Chaoran Yu <yuchaoran2...@gmail.com> wrote:
> 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 <w...@apache.org> 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 <apa...@craigcondit.com> > wrote: > > > >> Weiwei, > >> > >> 0.12.0 is burned. > >> > >> If a user attempts to depend on core@v0.12.0 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 <w...@apache.org> 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 < > >> wilfr...@apache.org> > >>> 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 <apa...@craigcondit.com> > >> 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 <yuchaoran2...@gmail.com> > >>>> 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: dev-unsubscr...@yunikorn.apache.org > >> For additional commands, e-mail: dev-h...@yunikorn.apache.org > >> > >> > >
