Odd version number

[cdrage]

dropbox/dev/go                                                                                                                                 
▶ opencompose version
v0.0.0+000000-not_a_git_tree

Should this be 0.1.0-alpha now?

[tnozicka]

@cdrage It should depending on where and how it was build.

Would you mind sharing where that binary came from or how did you build it?

[tnozicka]

Most likely an issue of not being build properly by make build. (We don't provide version info with go get and go build.)

https://github.com/redhat-developer/opencompose/blob/master/Makefile#L19-L24

[cdrage]

@tnozicka
All I did was a go get github.com/redhat-developer/opencompose. No building of myself.

I think go get should provide a version indicating it's from HEAD.

[pradeepto]

I could reproduce this. I did a go get as well. cc @tnozicka

[tnozicka]

I think go get should provide a version indicating it's from HEAD.
@cdrage technically it can't. But it say's not_a_git_tree.

You are right; the issue really is that go get is (no longer) a supported installation way from source.

The supported install way changed to:

go get -d github.com/redhat-developer/opencompose
make install -C $GOPATH/src/github.com/redhat-developer/opencompose/

README should reflect it shortly

[tnozicka]

Also Kubernetes, OpenShift and Docker behave the same way when build the unsupported go get way.

[cdrage]

@kadel @tnozicka @pradeepto

I really don't think we should dismiss go get simply because it doesn't fit into displaying the correct version (you'd just say HEAD as the version like Kompose does).

Many projects use go get as a simple way of installation from upstream / source.

If you want an "official" way, we should be curl/wget'ing a binary to -O /usr/local/bin and chmod +x'ing it.

[tnozicka]

Saying HEAD does not give you much but gets you into trouble. It is surely possible to switch, but that makes it unpredictable for external integrations parsing the version. That said I am willing to make a compromise here if that would be the general consensus. @pradeepto @kadel ? Kubernetes and OpenShift keep it parsable https://github.com/kubernetes/kubernetes/blob/master/pkg/version/base.go#L54

We don't dismiss go get, it is still possible if you wan't to just try it out. But the supported way is go get -d + make install if you wan't to file bug reports - that's what supported means. And for the majority of users there are binaries build with correct ldflags which are also the official and supported way.

[cdrage]

Ahhh I see what you mean with the Kubernetes project and how they do it, it's a good indication to see whether or not someone is using a tagged release! Following their conventions would be the best.

I agree with having the tagged releases being the supported way (for the majority of users like you said)

My question is.. what would the difference be (other than version.go having a different output) between between go get -u foobar and go get -d foobar + make install?

[tnozicka]

My question is.. what would the difference be (other than version.go having a different output) between between go get -u foobar and go get -d foobar + make install?

At this point the only difference is setting the version/commit variables with ldflags. Potentially we could add other features that require it, but I don't foresee any right now and I will do my best to keep go get working unless there is no better way like with this versioning feature.