Perhaps building your own version, with your own version string would be
sufficient? A general purpose feature to override the stated version with
an environment variable doesn't seem very applicable in many environments.
Perhaps there is a different way you could accomplish the same ultimate
goal?
On Wednesday, March 23, 2016, Zhitao Li <zhitaoli...@gmail.com> wrote:
> We want to have an external system to monitor or manage the full Mesos
> cluster, and neither the current "version" nor git_sha seems sufficient to
> determine whether a build being run is what we needed, especially when we
> move to our own packages.
>
> Being able to override the "version" key with an environment variable is
> probably sufficient for us.
>
> On Wed, Mar 23, 2016 at 4:51 PM, Vinod Kone <vinodk...@apache.org
> <javascript:_e(%7B%7D,'cvml','vinodk...@apache.org');>> wrote:
>
>> Not currently, no. What's your use case?
>>
>> On Wed, Mar 23, 2016 at 3:50 PM, Zhitao Li <zhitaoli...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','zhitaoli...@gmail.com');>> wrote:
>>
>>> Hi,
>>>
>>> Has anyone brought up the possibility of making the full version
>>> (i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?
>>>
>>> For example, when we are using the mesosphere community package, we want
>>> '0.27.1-2.0.226.debian81'
>>> string show up, but we only get the following right now:
>>>
>>> {
>>> "build_date": "2016-02-23 00:39:17",
>>> "build_time": 1456187957,
>>> "build_user": "root",
>>> "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
>>> "git_tag": "0.27.1",
>>> "version": "0.27.1"
>>> }
>>>
>>> Is there an environment variable or something which we could tweak at
>>> build/package time to get it? Thanks!
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>
>
> --
> Cheers,
>
> Zhitao Li
>
--
Text by Jeff, typos by iPhone
