sorry, mistake,
** My point is not criticize, but the way you describe the *how*
that pipeline should happen IRL.
That desciption seems taken from
controlled environment such as
- internal company
- oss distro
On Friday, May 5, 2017 at 2:57:44 PM UTC+2, mhh...@gmail.com wrote:
>
> yeah i agree.
yeah i agree.
But (:/), i think its pipeline issue in the consumption of a go package.
In the same way the language is made to prevent user errors (as much as
possible, and its difficult)
that go get pipeline usage should help in that matter too.
My point is not criticize, but the way you
On 5 May 2017, at 14:41, mhhc...@gmail.com wrote:
>
> Just to add on this that the fact i provide pre built bin is not winning
> against go get,
>
> The repo i took as example is providing,
> https://github.com/mh-cbon/emd/releases
>
> and all possible ways to install it i can provide,
>
Just to add on this that the fact i provide pre built bin is not winning
against go get,
The repo i took as example is providing,
https://github.com/mh-cbon/emd/releases
and all possible ways to install it i can provide,
https://github.com/mh-cbon/emd#install
So yeah i did my best, i loosed.
I totally agree with you and implemented such build pipeline.
But still, the fact is i have such situation,
I might run after each and every ticket like this,
that does not seem a run i can win ;)
On Friday, May 5, 2017 at 2:21:58 PM UTC+2, Jakob Borg wrote:
>
> For end users I strongly
For end users I strongly recommend distributing a binary. That gives you the
ability to tag it properly and to know what goes into it - your code, your
dependencies, and the compiler used. Typically this would happen by vendoring
and using a Makefile or build script in the repo, running on some
Hi,
For a program i provide a pre build binary built with
go install --ldflags "-X main.VERSION=$VERSION"
So when users met a problem they can report the version easily
and certainty.
the version variable is set by default to "0.0.0", could be empty string.
What should be the cmd line to
