Change:
<del> /* Copyright 2014 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package clock import ( "time" clocks "k8s.io/utils/clock" testclocks "k8s.io/utils/clock/testing" ) // PassiveClock allows for injecting fake or real clocks into code // that needs to read the current time but does not support scheduling // activity in the future. // // Deprecated: Use k8s.io/utils/clock.PassiveClock instead. type PassiveClock = clocks.PassiveClock // Clock allows for injecting fake or real clocks into code that // needs to do arbitrary things based on time. // // Deprecated: Use k8s.io/utils/clock.WithTickerAndDelayedExecution instead. type Clock = clocks.WithTickerAndDelayedExecution // Deprecated: Use k8s.io/utils/clock.RealClock instead. type RealClock = clocks.RealClock // FakePassiveClock implements PassiveClock, but returns an arbitrary time. // // Deprecated: Use k8s.io/utils/clock/testing.FakePassiveClock instead. type FakePassiveClock = testclocks.FakePassiveClock // FakeClock implements Clock, but returns an arbitrary time. // // Deprecated: Use k8s.io/utils/clock/testing.FakeClock instead. type FakeClock = testclocks.FakeClock // NewFakePassiveClock returns a new FakePassiveClock. // // Deprecated: Use k8s.io/utils/clock/testing.NewFakePassiveClock instead. func NewFakePassiveClock(t time.Time) *testclocks.FakePassiveClock { return testclocks.NewFakePassiveClock(t) } // NewFakeClock returns a new FakeClock. // // Deprecated: Use k8s.io/utils/clock/testing.NewFakeClock instead. func NewFakeClock(t time.Time) *testclocks.FakeClock { return testclocks.NewFakeClock(t) } // IntervalClock implements Clock, but each invocation of Now steps // the clock forward the specified duration. // // WARNING: most of the Clock methods just `panic`; // only PassiveClock is honestly implemented. // The alternative, SimpleIntervalClock, has only the // PassiveClock methods. // // Deprecated: Use k8s.io/utils/clock/testing.SimpleIntervalClock instead. type IntervalClock = testclocks.IntervalClock // Timer allows for injecting fake or real timers into code that // needs to do arbitrary things based on time. // // Deprecated: Use k8s.io/utils/clock.Timer instead. type Timer = clocks.Timer // Ticker defines the Ticker interface. // // Deprecated: Use k8s.io/utils/clock.Ticker instead. type Ticker = clocks.Ticker </del>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I discovered a need to update one of the two clock packages, and preparation for that revealed the divergent history of the two. One line of development can be seen in , and then It looks like early on that was cloned into , and from there we have an independent line of development: What you expected to happen: The two clock packages would be kept in sync for a while and then one removed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Whoops! Thanks for noticing! Tagging recent other editors: Which one should we keep?
I think the one in is necessary, because it is consumed by component-base, on which apimachinery depends. I created to start fixing the clock package in utils.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
/assign
- once and are merged in, the codebase will be fully migrated away from . How can we proceed with removal of this package? Is there some policy around this? /assign
^^ [I would personally vote for just removing it - maybe just leaving some "doc" file to point to the new location of that. But let's maybe wait for others.]
There seem to be a lot of out-of-tree uses of it ([lang][0]=Go) ... if it's easy to use type aliases to map to matching interfaces/implementations and mark the versions deprecated for a release or two, that would ease people updating library versions If that doesn't work or makes the package unmaintainable in some way, removing with a docs pointer seems ok.

Hey Before making any more changes, I wanted to get your opinion on where we go from here: Following , since we cannot modify the interface anymore, one obvious approach that I can think of would be to introduce a new interface in And in (the one to deprecate) Does this sound OK?
Friendly ping ^ :)
I don't have strong opinions about the transition in using a matching library version there is expected I'll defer to on the plan for the utils interface... defining a new interface is the only real way I see to stay backward compatible with the existing exposed go API there. To avoid repeating issues of the past, settle on the final/full interface you need to collapse onto before merging to utils
how does this sound to you wrt unblocking the migration?
This sounds good to me. Given that we migrated everything finally, I think this is ok.
Thanks Based on the above, I tested out how the migration would look locally by making point to my local clone which has and it looks as follows: Could you take a look whenever you get a chance and confirm if this is how we want to proceed? I just want to make sure that we are completely sure before making any more changes :)
Commented there
Hooray! Thanks, !