NFD

The de facto standard is to use the first 7 hex digits of the commit hash. However, I suggest just using git describe --always which automatically takes care of abbreviating the hash without compromising uniqueness.

The problem is that when somebody cloned with --depth 1, there is only one commit and git describe wouldn't know what length is enough for uniqueness. My client (gitx) shows 10 hex digits, that's why I chose 10 in the description.

The current implementation uses git describe (but with slightly different options), so it not exactly follows the proposal here :)

Alex Afanasyev wrote:

The problem is that when somebody cloned with --depth 1, there is only one commit and git describe wouldn't know what length is enough for uniqueness. My client (gitx) shows 10 hex digits, that's why I chose 10 in the description.

git itself uses 7 hex digits in the shallow clone case (I just checked with git clone --depth 1 && git describe --always).

I don't understand what the problem is with using --always unconditionally.

The NfdVersion component in ForwarderStatus is intended to show the API version of NFD, not the software version.

Software version of NFD cannot be obtained by nfd-status without a change to ForwarderStatus protocol, and I don't think this change is needed.

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

It is dangerous to display software version of either program on HTTP status page, because the exposed software version would allow an attacker to exploit a weakness in that specific software version.

Alex Afanasyev wrote:

I do not worry about any danger of exposing version. First, we are not at the stage to be worrying about such minor things. Second, even without knowing specific version, anybody can simply run set of known exploits. Hiding the version only harm us, since we cannot easily obtain and monitor the exact cersion installed.

I agree with Alex on this point.

I'm ok with changin the dataset. We could include both versions: one API and one actual version of the code. Or simply include version of the code.

I don't think we really want to give a potentially different version number to each tool/binary in NFD repo. Therefore, the HTTP server can just report its own version (or nfd-status's version) as the "code version", which makes things much simpler (no need to put it in the dataset). The "API version", on the other hand, can be kept separate.

See note-4:

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

And notice this issue is about nfd-status, not the HTTP server.

So there's nothing left to do.

Junxiao Shi wrote:

See note-4:

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

Well, if they're not, we should align the versions and make sure they stay aligned (e.g. all binaries use the same version number generated by waf)

The problem described is with http status server. The way I though to fix it was via changing nfd status output, which is requested by status server. I still think that in the long term it is a better approach (such a daset can be requested in the future remotely). Buy I'm ok directly returning version of status server, since it is normally be the same version of te running nfd.

I'm actually start to agree with an old comment, I think Davide made. There is no real value in "API" version and we can simply remove it and keep only commit-specific version.

API version is necessary.
After 1.0.0 release, API version would follow semantic versioning spec.

Software version can appear in addition to API version.
I'll update ForwarderStatus protocol for a new field.

I may be wrong, but I don't see how it can be used. I see its value for the library, but no so much for the forwarder.

what use cases for it you have in mind?

A client can obtain the API version of the forwarder, and decide how to interact with this forwarder.
It's a separate question on how to obtain the API version, but executing a command is one way.

I really don't see the need for all this complexity.

One version number is enough. One version for the whole NFD repo, the same version that is used to tag releases, shared across all tools and daemons, which is also equivalent to the "forwarder API version" (whatever that means), and incremented according to the semantic versioning scheme. Period.

Using more than one version number only leads to confusion (think about user support), is very difficult to maintain, and brings no benefit.

A version number conforming to Semantic Versioning has the form MAJOR.MINOR.PATCH.

git --describe is unable to supply such a version number automatically.

Are you suggesting that EVERY commit must change the version number in wscript?

Junxiao Shi wrote:

A version number conforming to Semantic Versioning has the form MAJOR.MINOR.PATCH.

git --describe is unable to supply such a version number automatically.

Quoting the same document you linked:

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

It seems to me that the output of git describe is perfectly valid (excluding the first "v" which is part of the tag). The "lower precedence" part could be a problem, but I don't think that part of the specification has much importance. If you think that's a problem, we can simply replace the first hyphen with a plus sign (wrt point 10 of the semver spec).