The RESTAPI gets the value of the "version" attribute from the "VdcVersion" configuration option, so that is what needs to be fixed. To verify please check the result of the following:

  # rhevm-config -s VdcVersion=3.5.1.0
  # service ovirt-engine restart

Then try again to get the version from the RESTAPI, it should be 3.5.1.0.

I checked it and it works.
Steps:
1. set version with rhevm config: rhevm-config -s VdcVersion=3.5.1.0
2. service ovirt-engine restart
3. Get version with REST: 
<version major="3" minor="5" build="1" revision="0"/>
<full_version>3.5.1-0.2.el6ev</full_version>

It is engine problem with the vds version.

According to the code, the VdcVersion (version) and ProductRPMVersion (full_version), are both set for the 3.5.0.0.
Where are you getting 3.5.1-0.2.el6ev?
Can we access the installation?

Connect via REST API to http://<engine>/api
look for:
<version major  ....>
<full_version> ..</full_version>

(In reply to Israel Pinto from comment #4)
> Connect via REST API to http://<engine>/api
> look for:
> <version major  ....>
> <full_version> ..</full_version>

I understand that.... I was asking where did you see that? in what version? what build?

vt14.1

(In reply to Oved Ourfali from comment #3)
> According to the code, the VdcVersion (version) and ProductRPMVersion
> (full_version), are both set for the 3.5.0.0.
> Where are you getting 3.5.1-0.2.el6ev?

It's set by engine-setup [1].

[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/config/plugins/ovirt-engine-setup/ovirt-engine/config/options.py;h=8acf431b4d390e6bf0c9b526cd5a21bc8334c820;hb=HEAD#l156

Patch posted: 

  https://gerrit.ovirt.org/#/c/39906/1

(In reply to Israel Pinto from comment #0)
> Description of problem:
> Connect via REST API to http://<engine>/api
> in the response there is mismatch between version and full version, like:
> <version major="3" minor="5" build="0" revision="0"/>
> <full_version>3.5.1-0.2.el6ev</full_version>
> 
> Actual results:
> mismatch between version and full version
> 
> Expected results:
> The version match the full version

Why?

> 
> It also happens in other APIs

Please see also bug 905398.

Patch merged: 

  https://gerrit.ovirt.org/#/c/40085/

Ori, why has the patch been merged? There's an open needinfo on Israel Pinto about this change being not needed.

(In reply to Yedidyah Bar David from comment #9)
> (In reply to Israel Pinto from comment #0)
> > Description of problem:
> > Connect via REST API to http://<engine>/api
> > in the response there is mismatch between version and full version, like:
> > <version major="3" minor="5" build="0" revision="0"/>
> > <full_version>3.5.1-0.2.el6ev</full_version>
> > 
> > Actual results:
> > mismatch between version and full version
> > 
> > Expected results:
> > The version match the full version
> 
> Why?
> 
> > 
> > It also happens in other APIs
> 
> Please see also bug 905398.

It makes no sense to write build = 0 when we refer to 3.5.1.
The fix addresses that.

(In reply to Oved Ourfali from comment #12)
> (In reply to Yedidyah Bar David from comment #9)
> > (In reply to Israel Pinto from comment #0)
> > > Description of problem:
> > > Connect via REST API to http://<engine>/api
> > > in the response there is mismatch between version and full version, like:
> > > <version major="3" minor="5" build="0" revision="0"/>
> > > <full_version>3.5.1-0.2.el6ev</full_version>
> > > 
> > > Actual results:
> > > mismatch between version and full version
> > > 
> > > Expected results:
> > > The version match the full version
> > 
> > Why?
> > 
> > > 
> > > It also happens in other APIs
> > 
> > Please see also bug 905398.
> 
> It makes no sense to write build = 0 when we refer to 3.5.1.
> The fix addresses that.

It does, if this is our "api compatibility version", if we have such a thing.

I read the discussion on bug 905398 and can't clearly understand if we have such a thing, if we intend to have such a thing, etc.

Are client applications expected to check this version and decide what's supported/unsupported accordingly? Do we publish this anywhere? Or is this just for reporting?

What do we have VdcVersion for, then? Do we publish or check it anywhere?

Juan - do you have information on who uses <version> and for what reason?

(In reply to Yedidyah Bar David from comment #13)
> It does, if this is our "api compatibility version", if we have such a thing.

It isn't, the version numbers presented here, both "version" and "full_version", are informative only, they don't have any meaning other than identifying the version of the product.

> I read the discussion on bug 905398 and can't clearly understand if we have
> such a thing, if we intend to have such a thing, etc.

We don't have such a thing and we don't have short term plans to have it.

> Are client applications expected to check this version and decide what's
> supported/unsupported accordingly? Do we publish this anywhere? Or is this
> just for reporting?

Applications can check this version, but they aren't expected or required to do it, and as far as I know no application does so, including our own SDKs and CLI. 

Applications can cross check this information with the information available in the /capabilities resource, where we list the features of each X.Y version. However the information about features available in the /capabilities resource is basically textual, hard to consume for applications, so I think that no application is actually using it.

verified on 3.6.0-0.0.master.20150519172222.git9a2e2b3.el7

*** Bug 1284654 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html