Replace custom version code with semver about rivine HOT 5 CLOSED

I would like the original SemVer variable to be parsed from a string variable, this way I can add it to the buildscript to inject that string (being the git describe version string)

from rivine.

Since this issue was made, we did start using a minimal version of semver, specifically restricted for our purposes.

Because the problem with semver libraries (eg https://github.com/blang/semver), is that they can contain way too much data, and especially data which we cannot really easily serialize over the wire, using the Sia protocol. If you check https://github.com/blang/semver/blob/master/semver.go#L24-L30, that's really a nightmare to serialize over the Sia protocol, and also way too much data for what it is.

So I see 2 roads:

• either we stick with our custom one-file version module, which might be good enough for our specialized purposes;
• we wrap around a library (eg github.com/blang/semver) handicapping it to fit our needs (eg in the serialization department);

If we stick with our custom one-line version module (which is newer than this issue), we have to:

• Make a MustVersionFromString function, which wraps around VersionFromString and panics in case of an error, this would allow us to have a string variable injected as you want. This one is easy enough as the biggest chunk of work is already done (parsing from strings);
• In case we want to get the build version from git describe, which gets the versions, we would need to really be disciplined in using versioning that fits within our supported scheme. Right now if I do git describe I get "v0.1.0-1-g805e96d", which is illegal in the current scheme. v0.1.0-g805e96d would be legal, as for now I only allow 1 pre-release tag (limited to 8 bytes);

The good thing about our custom one-line version module is that it is really perfect to wire over the sia protocol, as the output string is a fixed size. If you check the ProtocolVersion struct for yourself, you can see that the only thing it has to serialize is one uint32 and an array ([8]byte). In case you think it will be needed to allow for greater versions than 255.255.255, we can also go for an uint64 instead of an uint32. We also still have 8 bits available, so in theory we could even support a 4th number after the patch number, as in 255.255.255.255, but dunno that becomes a bit much. I have a feeling that a major+minior+patch version AND a commit 8-byte commit hash, should be sufficient to represent versions, but perhaps I'm missing something here.

A bit unrelated, I am not a too big fan of the wiring protocol of Sia and how it (de)serializes stuff, directly from struct fields, with no real structure. Meaning that everything really has to be static in size, AFAIK.

Personally I would ratter go for a structured encoding format for our wiring protocol, such as bencoding, which is still minimalistic, but at least we would have some sane structure, instead of just raw struct data.

Please let me know your opinions on these 2 (slightly related) topics, and I'll take it from there @robvanmieghem. The first part of my comment is obviously the important one for this issue.

from rivine.

@GlenDC I agree with the wiring protocol being structured more would be a very good thing.

For the version string, having v0.1.0-g805e96d instead of v0.1.0-1-g805e96d is fine, we do need to 'cut out the the number of commits away from tag' in the publish script then and indeed, no point in including a full blown semver lib if we don't really need it.

from rivine.

Or we have a seperate buildversion where we just use the entire git describe string and a protocolversion that only takes the vx.y.z string.

from rivine.

I think I would prefer you first suggestion. Although in theory I don't think it is ever needed to start comparing remote with local versions, more specific than the patch level. But perhaps that's something we can address later when we take more control over the wiring protocol. For now I would go for you first suggestion, as I don't think it's too important at this point.

Which build scripts do you want to inject it at? I can add that code as well as part of the PR I'll make than.

from rivine.