dep version

[nathany]

It would be helpful to know which version of dep I'm using when reporting issues. Right now the best I can do is use go log -1 in the golang/dep folder.

That doesn't always work though, as I recently failed to install the new version of dep.

Usually I'd use -ldflags with git rev-parse --short HEAD and such when building the tool, likely with a Makefile to do the build. That isn't ideal for go get use though. Suggestions?

[peterbourgon]

We don't have versions, nor (IMO) should we, until we get a bit more stable.

[nathany]

Thanks @Mattn for giving it a go. I was thinking more along the lines of the git sha in the binary to start, along with an issue template. Fine by me to hold off though.

[zachgersh]

I actually agree with @nathany's suggestion of at the very least adding the git sha that the binary was built off of as the version for now. I know personally that using a binary and then having to trace back what commit it was built off of is _slightly_ painful. @peterbourgon is there any real reason not to include at least the sha or is that a reasonable compromise here?

[peterbourgon]

Yes, it's not possible to embed a version or git SHA and still be able to fetch the client with go get. At some point we'll do versioned releases but IMHO it doesn't make sense to opt-in to that extra tedious process until we at least stabilize the file formats.

[sdboyer]

File formats are stabilized, v0.1.0 release is rolled - we can start thinking about this now 😄

[ibrasho]

Do we have a preferred approach to how versions are marked?
go get won't allow users to specify versions. Do we have plans for alternative install methods?

[ibrasho]

I found 2 PRs related to this (I believe there is a third one but I'm not able to relocated it):

51 uses Make and write version to text file, it prints the version, the commit sha1, GOOS & GOARCH.

210 has version as a const within the command .go file

[peterbourgon]

Versions are marked as tags in the repo of the form vX.Y.Z.
http://semver.org/

go get does not respect versions but dep ensure does when it populates
the vendor folder.

On Sat, May 27, 2017 at 8:03 PM, Ibrahim AshShohail <
[email protected]> wrote:

Do we have a preferred approach to how versions are marked?
go get won't allow users to specify versions. Do we have plans for
alternative install methods?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/209#issuecomment-304467527, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAG_TVbDESB0z65o4hGI1xoKvA-PsRSIks5r-GWEgaJpZM4LzUrl
.

[peterbourgon]

Oh, lord, I just realized I answered a question you didn't ask. Please
disregard :facepalm:

On Mon, May 29, 2017 at 8:57 AM, Peter Bourgon [e-mail] wrote:

Versions are marked as tags in the repo of the form vX.Y.Z.
http://semver.org/

go get does not respect versions but dep ensure does when it populates
the vendor folder.

On Sat, May 27, 2017 at 8:03 PM, Ibrahim AshShohail <
[email protected]> wrote:

Do we have a preferred approach to how versions are marked?
go get won't allow users to specify versions. Do we have plans for
alternative install methods?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/209#issuecomment-304467527, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAG_TVbDESB0z65o4hGI1xoKvA-PsRSIks5r-GWEgaJpZM4LzUrl
.

[ibrasho]

It's totally ok. 🤣🤣🤣 I can see how you might misunderstand my question. 🤣🤣🤣

[embano1]

Just wanted to bring this up again. v0.2.0 has been released. IMHO it makes sense now (especially since more and more people are switching to dep) to introduce a version flag for dep.

[sdboyer]

yeah, we need to do...something. unfortunately, we're still victims of the same basic issue that everyone else has - having a version flag behave correctly requires having a makefile, or some other strategy that's incompatible with go get.

i'd love to have someone champion getting this done, with the understanding that it really being _done_ involves not just creating a subcommand/flag/whatever, but also updating our CI, our docs, and our github templates accordingly.