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

bad jaeger tagged release #331

Closed
lizthegrey opened this issue Nov 19, 2019 · 9 comments · Fixed by #502
Closed

bad jaeger tagged release #331

lizthegrey opened this issue Nov 19, 2019 · 9 comments · Fixed by #502
Assignees

Comments

@lizthegrey
Copy link
Member

lizthegrey commented Nov 19, 2019

https://pkg.go.dev/mod/go.opentelemetry.io/otel/exporter/trace/jaeger@v1.0.0?tab=versions

we incorrectly created v1.0.0 on November 4 and now Go module proxy has cached it.

we should investigate whether we can get it purged.

@jmacd
Copy link
Contributor

jmacd commented Nov 21, 2019

@marwan-at-work says this is permanently cached in the Go team's checksum database, which is a security mechanism for Go modules. We may have trouble re-using this tag.

@lizthegrey
Copy link
Member Author

this also causes someone running go get -u [...] to pull the bad version as it's the "latest"...

@ferhatelmas
Copy link
Contributor

Relevant issue - golang/go#34189

I asked for the clarification of this case in a comment.

@lizthegrey
Copy link
Member Author

golang/go#24031 probably would resolve this issue by allowing us to badlist the v1.0.0 release.

@paivagustavo
Copy link
Member

We should probably look for a workaround for this since there is no clear solution other than waiting for version v1.0.1 to come out. People are starting facing issues because of this. Some examples of the people that faced this:

One possible solution that I have suggested on gitter is renaming the package, that should fix the problem.

@wingyplus
Copy link
Contributor

wingyplus commented Feb 11, 2020

@paivagustavo how about go get jaeger module with goproxy direct mode for now until this lib reach 1.0.0?

@lizthegrey
Copy link
Member Author

agree renaming package makes good sense.

@MrAlias
Copy link
Contributor

MrAlias commented Feb 27, 2020

I'm planning to go with the suggestion made in the 2020-02-13 SIG meeting:

Suggestion was to rename the “exporter” part of the URL to “exporters”. This would affect all the exporters, but given the alpha state it seemed reasonable.

Unless there is an alternate naming suggestion.

@lizthegrey
Copy link
Member Author

Agree, good idea.

MrAlias referenced this issue in MrAlias/opentelemetry-go Feb 28, 2020
The `go.opentelemetry.io/otel/exporter/trace/jaeger` package was
mistakenly released with a `v1.0.0` tag instead of `v0.1.0`. This
resulted in all subsequent releases not becoming the default latest,
meaning that `go get`s pulled in the incompatible `v0.1.0` release of
that package when pulling in more recent packages from other otel
packages. Renaming the `exporter` directory to `exporters` fixes this
issue by consequentially renaming the package.

Additionally, this action also renames *all* exporters. This is
understood to be a disruptive action to existing users as they will need
to update any dependencies they currently have on our exporters.
However, it was decided to take this action regardless. The need to
resolve the existing issue explained above is highly important, and
given the Alpha state of this project these kinds of breaking changes
should be expected (though not without reason).

Resolves #331
rghetia added a commit that referenced this issue Mar 2, 2020
The `go.opentelemetry.io/otel/exporter/trace/jaeger` package was
mistakenly released with a `v1.0.0` tag instead of `v0.1.0`. This
resulted in all subsequent releases not becoming the default latest,
meaning that `go get`s pulled in the incompatible `v0.1.0` release of
that package when pulling in more recent packages from other otel
packages. Renaming the `exporter` directory to `exporters` fixes this
issue by consequentially renaming the package.

Additionally, this action also renames *all* exporters. This is
understood to be a disruptive action to existing users as they will need
to update any dependencies they currently have on our exporters.
However, it was decided to take this action regardless. The need to
resolve the existing issue explained above is highly important, and
given the Alpha state of this project these kinds of breaking changes
should be expected (though not without reason).

Resolves #331

Co-authored-by: Rahul Patel <rghetia@yahoo.com>
hstan referenced this issue in hstan/opentelemetry-go Oct 15, 2020
…compatible in /instrumentation/host (#331)

* Bump github.com/shirou/gopsutil in /instrumentation/host

Bumps [github.com/shirou/gopsutil](https://github.com/shirou/gopsutil) from 2.20.7+incompatible to 2.20.8+incompatible.
- [Release notes](https://github.com/shirou/gopsutil/releases)
- [Commits](shirou/gopsutil@v2.20.7...v2.20.8)

Signed-off-by: dependabot[bot] <support@github.com>

* Auto-fix go.sum changes in dependent modules

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: dependabot[bot] <dependabot[bot]@users.noreply.github.com>
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
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

Successfully merging a pull request may close this issue.

7 participants