Skip to content
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 deprecation notice in favor of github.com/gofrs/uuid and archive this repo #84

Open
theckman opened this issue Jul 19, 2018 · 4 comments

Comments

@theckman
Copy link

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.

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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
@theckman
Copy link
Author

theckman commented Dec 5, 2018

@satori any thoughts on this?

@fawkesley
Copy link

@theckman Thanks for pointing me to the fork. Got tripped up by the release being out of date (#82) so I appreciate this.

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 [email protected] 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 <[email protected]>
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
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
@cleverlzc
Copy link

cleverlzc commented Jan 22, 2022

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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Co-authored-by: Kanika Rana <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants