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 < ***@***.***> 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 <#209 (comment)>, 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 🤦

…

On Mon, May 29, 2017 at 8:57 AM, Peter Bourgon ***@***.***> 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 < ***@***.***> 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 > <#209 (comment)>, 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.