You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yunikorn.apache.org by Chaoran Yu <yu...@gmail.com> on 2021/12/14 00:13:40 UTC
Renaming v0.12.0 to v0.12.1
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
Re: Renaming v0.12.0 to v0.12.1
Posted by Weiwei Yang <ww...@apache.org>.
Thank you Chaoran!
On Mon, Dec 13, 2021 at 5:33 PM Chaoran Yu <yu...@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 <ww...@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 <ap...@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 <ww...@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 <
> >> wilfreds@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 <ap...@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 <yu...@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-unsubscribe@yunikorn.apache.org
> >> For additional commands, e-mail: dev-help@yunikorn.apache.org
> >>
> >>
>
>
Re: Renaming v0.12.0 to v0.12.1
Posted by Chaoran Yu <yu...@gmail.com>.
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 <ww...@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 <ap...@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 <ww...@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 <
>> wilfreds@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 <ap...@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 <yu...@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-unsubscribe@yunikorn.apache.org
>> For additional commands, e-mail: dev-help@yunikorn.apache.org
>>
>>
Re: Renaming v0.12.0 to v0.12.1
Posted by Weiwei Yang <ww...@apache.org>.
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 <ap...@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 <ww...@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 <
> wilfreds@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 <ap...@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 <yu...@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-unsubscribe@yunikorn.apache.org
> For additional commands, e-mail: dev-help@yunikorn.apache.org
>
>
Re: Renaming v0.12.0 to v0.12.1
Posted by Craig Condit <ap...@craigcondit.com>.
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 <ww...@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 <wi...@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 <ap...@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 <yu...@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-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org
Re: Renaming v0.12.0 to v0.12.1
Posted by Weiwei Yang <ww...@apache.org>.
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 <wi...@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 <ap...@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 <yu...@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
> > >
> > >
> >
> >
>
Re: Renaming v0.12.0 to v0.12.1
Posted by Wilfred Spiegelenburg <wi...@apache.org>.
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 <ap...@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 <yu...@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
> >
> >
>
>
Re: Renaming v0.12.0 to v0.12.1
Posted by Craig Condit <ap...@craigcondit.com>.
+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 <yu...@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
>
>