-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "AtTime" generators for V1, V6, and V7 #142
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #142 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 5 5
Lines 447 459 +12
=========================================
+ Hits 447 459 +12 ☔ View full report in Codecov by Sentry. |
Nice. Looks good so far. I think it was the right call to add some additional functions. As a mega nit, what do you think of the convention |
Personally, I like
All that said, I really don't care if you want to change it. |
@kohenkatz Dependabot updated the go-setup github action, and I noted we were testing against older versions of go so I took the opportunity to kick them up to latest and latest -1. Might be worth rebasing against master :) |
@kohenkatz Hi, heads up, I fat fingered the update branch button. You'll want to do a pull when you pick this back up again. Apologies. |
ee708e7
to
ad2043b
Compare
After what seems like forever, this PR now has tests! Ready for review once again. |
// Generator provides an interface for generating UUIDs. | ||
type Generator interface { | ||
NewV1() (UUID, error) | ||
NewV1AtTime(time.Time) (UUID, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd hate to create a new major version for this, but this is pedantically a breaking change if any consumer has their own implementation of the Generator
interface.
At a minimum, we should call out that there are 3 new methods on this interface so that consumers will have a pointer to the source of their broken builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine to remove from the interface, but that will mean we cannot use the package-level convenience methods, because those operate using DefaultGenerator
which uses this interface.
This just means that to use the new methods users will need to create a custom generator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not against adding the methods to the interface, we just need to decide whether we bump to v6.x or we accept what is technically a breaking change in a v5.x minor release and "fix with words" for any consumers that have their own implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd go with jumping to 6.x. It's not such a big deal to make the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Easy enough for this code, but It's a much bigger deal for every consumer to have to update every import to s|v5|v6
😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, there's no way for us to know how many consumers are implementing the interface separately. Numbers like that would be very useful to this decision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
per pkg.go.dev, 749 public things import /v5. I know we have a bunch of internal modules at work that also import it.
I can confirm that we don't have any custom Generator
implementations and someone could theoretically check all of those public importers, but it's impossible to know if any non-public consumers will break.
Personally, I feel like the odds are very low that this will actually be a breaking change and we should do a v5.x minor release with a note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me, but we probably should wait for at least one additional voice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes LGTM with the added tests, but we need to make a call on the breaking change to the Generator
interface.
Super nit: I think I would prefer to only include the full details for a variant on just one of the New*()
functions rather than have it repeated 4X across the 2 New*()
functions and the 2 Gen
methods.
Thank you very much @kohenkatz . Regarding the discussion around releasing it as a minor or major, I think the likelihood of a consumer implementing a custom generator is unlikely due to the extremely niche functionality it offers, and I suspect we won't be impacting much by releasing it as a minor. |
This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [github.com/gofrs/uuid/v5](https://redirect.github.com/gofrs/uuid) | `v5.2.0` -> `v5.3.0` | [![age](https://developer.mend.io/api/mc/badges/age/go/github.com%2fgofrs%2fuuid%2fv5/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/go/github.com%2fgofrs%2fuuid%2fv5/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/go/github.com%2fgofrs%2fuuid%2fv5/v5.2.0/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/go/github.com%2fgofrs%2fuuid%2fv5/v5.2.0/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>gofrs/uuid (github.com/gofrs/uuid/v5)</summary> ### [`v5.3.0`](https://redirect.github.com/gofrs/uuid/releases/tag/v5.3.0) [Compare Source](https://redirect.github.com/gofrs/uuid/compare/v5.2.0...v5.3.0) #### Summary In this release, we updated the package to participate in OpenSSF Scorecard and tuned several development workflows and added some fuzz tests. Additionally, We added `AtTime` generators for V1, V6, and V7 so that users may generate UUIDs from time stamps. **NOTE** Technically, the additional of the `AtTime` generators is a breaking change to the `Generator` interface. We decided to go with a `minor` update because of the unlikelihood of this interface being implemented by a consumer, and to reduce the impact of releasing a major version for this feature. #### What's Changed - Add "AtTime" generators for V1, V6, and V7 by [@​kohenkatz](https://redirect.github.com/kohenkatz) in [https://github.com/gofrs/uuid/pull/142](https://redirect.github.com/gofrs/uuid/pull/142) - Fix typo in URL in README by [@​kohenkatz](https://redirect.github.com/kohenkatz) in [https://github.com/gofrs/uuid/pull/141](https://redirect.github.com/gofrs/uuid/pull/141) - Add OpenSSF Best Practices Badge to README by [@​cameracker](https://redirect.github.com/cameracker) in [https://github.com/gofrs/uuid/pull/144](https://redirect.github.com/gofrs/uuid/pull/144) - Create SECURITY.md by [@​cameracker](https://redirect.github.com/cameracker) in [https://github.com/gofrs/uuid/pull/143](https://redirect.github.com/gofrs/uuid/pull/143) - Add OpenSSF Scorecard badge to readme by [@​cameracker](https://redirect.github.com/cameracker) in [https://github.com/gofrs/uuid/pull/149](https://redirect.github.com/gofrs/uuid/pull/149) - Update fuzz tests to use go fuzz features by [@​cameracker](https://redirect.github.com/cameracker) in [https://github.com/gofrs/uuid/pull/148](https://redirect.github.com/gofrs/uuid/pull/148) #### New Contributors - [@​ldez](https://redirect.github.com/ldez) made their first contribution in [https://github.com/gofrs/uuid/pull/168](https://redirect.github.com/gofrs/uuid/pull/168) **Full Changelog**: gofrs/uuid@v5.2.0...v5.3.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - "before 6am on Monday" in timezone Europe/Paris, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/cozy/cozy-stack). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC43NC4xIiwidXBkYXRlZEluVmVyIjoiMzguNzQuMSIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
This PR implements the request in #84 to be able to create UUIDs at specific known timestamps, in addition to the current time.
Although that request only mentions UUIDv1, this PR also includes the other two time-based UUID versions, namely v6 and v7.
To prevent code duplication, this PR reimplements
NewV1
,NewV6
, andNewV7
to each call their respectiveNewV<X>AtTime
with the providedEpochFunc
, which defaults to providing the current time.This PR will remain a draft until I have time to write some tests...