Add deprecation notice in favor of github.com/gofrs/uuid and archive this repo #84
Comments
theckman
added a commit
to theckman/go.uuid
that referenced
this issue
Jul 19, 2018
This change adds a deprecation notice to the README to point users to the fork now maintained by The Gofrs ([github.com/gofrs/uuid](https://github.com/gofrs/uuid). It also suggest that they make use of v2.0.0 or newer. Fixes satori#84 Signed-off-by: Tim Heckman <t@heckman.io>
theckman
added a commit
to theckman/go.uuid
that referenced
this issue
Jul 19, 2018
This change adds a deprecation notice to the README and package docs to point users to the fork now maintained by The Gofrs ([github.com/gofrs/uuid](https://github.com/gofrs/uuid). It also suggests that they make use of v2.0.0 or newer. Fixes satori#84 Signed-off-by: Tim Heckman <t@heckman.io>
theckman
added a commit
to theckman/go.uuid
that referenced
this issue
Jul 19, 2018
This change adds a deprecation notice to the README and package docs to point users to the fork now maintained by The Gofrs ([github.com/gofrs/uuid](https://github.com/gofrs/uuid)). It also suggests that they make use of v2.0.0 or newer. Fixes satori#84 Signed-off-by: Tim Heckman <t@heckman.io>
mikecook
pushed a commit
to ticketmaster/terraform-provider-apigee
that referenced
this issue
Aug 15, 2018
bflad
added a commit
to hashicorp/terraform-provider-aws
that referenced
this issue
Aug 28, 2018
Prefer to use upstream helper/acctest.RandomWithPrefix instead. See also: satori/go.uuid#84
oz
added a commit
to oz/lile
that referenced
this issue
Oct 8, 2018
Seeing the inactivity of the satori/go.uuid repository, a group of Go developers has stepped up to maintain it, fixing a few issues. It does not cost much, and also improves Lile. ✨ See also: satori/go.uuid#84
xizhibei
added a commit
to xizhibei/gocelery
that referenced
this issue
Nov 1, 2018
|
@satori any thoughts on this? |
ghost
mentioned this issue
whilei
added a commit
to whilei/leaps
that referenced
this issue
Dec 22, 2018
It appears github.com/satori/go.uuid is functionally deprecated, and has been superceded by github.com/gofrs/uuid. - satori/go.uuid#84 - satori/go.uuid#90 This came to my attention because of un-tagged changes to satori/go.uuid that changed the signature of uuid.NewV4() from a single return val to two, resulting in: $ go get github.com/Jeffail/leaps/cmd/... warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www # github.com/Jeffail/leaps/lib/util go/src/github.com/Jeffail/leaps/lib/util/uuid_gen.go:51:19: multiple-value uuid.NewV4() in single-value context Of course running 'dep ensure' fixed this issue, but it seems like this project should use the 'longer fork' of this dependency in any case. This change does NOT address the 'what to do with the error value' question; it just ignores the possible error.
dgervais
added a commit
to dgervais/spire
that referenced
this issue
Dec 26, 2018
Gopkg.toml version of go.uuid@1.2.0 did not include non-random uuid fix: satori/go.uuid#73 also, deprecation notice for satori/go.uuid posted via issue: satori/go.uuid#84 community recommended replacement is available at github.com/gofrs/uuid * updated Gopkg.toml to use github.com/gofrs/uuid @ 3.1.2 * rebuilt Gopkg.lock * incorporate symmantics of uuid.NewV4() can return error Signed-off-by: David Gervais <dgervais@gmail.com>
This was referenced Jul 18, 2020
3 tasks
mergify bot
added a commit
to tinkerbell/tink
that referenced
this issue
Sep 9, 2020
## Description The PR changes UUID package from `github.com/satori/go.uuid` to `to github.com/google/uuid`. ## Why is this needed The package `github.com/satori/go.uuid` is not actively maintained anymore and will eventually be marked as deprecated. References: - [NewV4: non-random uuid](satori/go.uuid#73) - [PSA: This repo is dead](satori/go.uuid#103) - [Add deprecation notice in favor of github.com/gofrs/uuid and archive this repo](satori/go.uuid#84) ## How Has This Been Tested? CI and Tests pass. ## How are existing users impacted? What migration steps/scripts do we need? No impact. ## Checklist: I have: - [ ] updated the documentation and/or roadmap (if required) - [ ] added unit or e2e tests - [ ] provided instructions on how to upgrade
This was referenced Mar 2, 2021
Closed
This was referenced May 4, 2021
This was referenced May 18, 2021
Closed
s7v7nislands
pushed a commit
to s7v7nislands/bytebase
that referenced
this issue
Jul 13, 2021
IMPORTANT: Unresolved CVE on latest release (CVE-2021-3538 ) satori/go.uuid#115 Add deprecation notice in favor of github.com/gofrs/uuid and archive this repo satori/go.uuid#84 more issues: https://github.com/satori/go.uuid/issues/ use github.com/google/uuid, which is more active
|
good issue, it(satori/go.uuid) should be |
mikelolasagasti
added a commit
to mikelolasagasti/kube-burner
that referenced
this issue
Jan 15, 2024
satori/uuid repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the "NewString" function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do.
mikelolasagasti
added a commit
to mikelolasagasti/kube-burner
that referenced
this issue
Jan 15, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the "NewString" function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do.
mikelolasagasti
added a commit
to mikelolasagasti/kube-burner
that referenced
this issue
Jan 15, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do.
mikelolasagasti
added a commit
to mikelolasagasti/kube-burner
that referenced
this issue
Jan 15, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
7 tasks
rsevilla87
pushed a commit
to kube-burner/kube-burner
that referenced
this issue
Jan 16, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
rsevilla87
pushed a commit
to rsevilla87/kube-burner
that referenced
this issue
Jan 16, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
rsevilla87
pushed a commit
to kube-burner/kube-burner-ocp
that referenced
this issue
Jan 16, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
rsevilla87
pushed a commit
to rsevilla87/kube-burner-ocp
that referenced
this issue
Jan 23, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists, IMO Google's module is simpler, even if the `NewString` function can be bit confusing as doesn't reference UUID V4 in the name as satori's and other modules do. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
mikelolasagasti
added a commit
to mikelolasagasti/ksctl
that referenced
this issue
Apr 19, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists to continue `satori/uuid`, Google's module is simpler and already used as indirect dependency. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
mikelolasagasti
added a commit
to mikelolasagasti/ksctl
that referenced
this issue
Apr 20, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists to continue `satori/uuid`, Google's module is simpler and already used as indirect dependency. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
alexeykazakov
pushed a commit
to kubesaw/ksctl
that referenced
this issue
May 2, 2024
`satori/uuid` repo is dead and has different problems as shown in satori/go.uuid#84 Although a fork exists to continue `satori/uuid`, Google's module is simpler and already used as indirect dependency. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info> Co-authored-by: Kanika Rana <46766610+ranakan19@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an issue to request that a deprecation notice be added to the README that points users to the fork created by some of us in the community (The Gofrs). In addition to that, it'd be good to mark the repo as being "archived" in the GitHub settings so that users get a nice warning that it's no longer maintained.
We plan to keep our fork maintained, as well as to include some of the feature requests / PRs on this repo.
This being done would, in some way, fix #73, #76, #80, #82, and #83.
This new repo also contains something similar to #75, and will hopefully include iterations of #44 and #50.
The text was updated successfully, but these errors were encountered: