RejectedSoftware Forums

Sign up

Combined SemVers for bindings

Sure this topic came up already several times, but I could find only this here:
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2919/

I am maintaining a binding/loader where the original is updated quite frequently. The binding is auto generated from a python script which I do not have to touch other then execute when the original is updated and new bindings get generated. Hence I would prefer double SemVers as (with arbitrary separator):

v'BindingScriptVer'+v'BoundOriginalVer'

I saw this versioning pattern on several dub packages but there is no official specification. More over it is not clear if an update is triggered when the second version is incremented but not the first (apparently not, see link above).

What is your opinion regarding this issue?

Re: Combined SemVers for bindings

Am 01.03.2018 um 10:15 schrieb ParticlePeter:

Sure this topic came up already several times, but I could find only this here:
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2919/

I am maintaining a binding/loader where the original is updated quite frequently. The binding is auto generated from a python script which I do not have to touch other then execute when the original is updated and new bindings get generated. Hence I would prefer double SemVers as (with arbitrary separator):

v'BindingScriptVer'+v'BoundOriginalVer'

I saw this versioning pattern on several dub packages but there is no official specification. More over it is not clear if an update is triggered when the second version is incremented but not the first (apparently not, see link above).

What is your opinion regarding this issue?

AFAIK, this is the best thing that can be done within SemVer. The +
suffix is specified to have no semantic meaning in terms of version
precedence (using "SHOULD" notation, though). But regardless, the
regular version must indeed always be incremented to make upgrading work
properly.

Since the bindings will usually diverge from the original version
(unless that uses SemVer in the first place), it also makes sense to
always start with 1.0.0.

Re: Combined SemVers for bindings

On Sun, 4 Mar 2018 13:35:26 +0100, Sönke Ludwig wrote:
[snip]

AFAIK, this is the best thing that can be done within SemVer. The +
suffix is specified to have no semantic meaning in terms of version
precedence (using "SHOULD" notation, though). But regardless, the
regular version must indeed always be incremented to make upgrading work
properly.

Does this mean that the parsing of SemVer is not customize-able on your side?
So how about e.g. and optional secondary SemVer in the file format. It would not be possible to consider this secondary to trigger the update mechanics?

Re: Combined SemVers for bindings

On Sun, 04 Mar 2018 19:39:29 GMT, ParticlePeter wrote:

On Sun, 4 Mar 2018 13:35:26 +0100, Sönke Ludwig wrote:
[snip]

AFAIK, this is the best thing that can be done within SemVer. The +
suffix is specified to have no semantic meaning in terms of version
precedence (using "SHOULD" notation, though). But regardless, the
regular version must indeed always be incremented to make upgrading work
properly.

Does this mean that the parsing of SemVer is not customize-able on your side?
So how about e.g. and optional secondary SemVer in the file format. It would not be possible to consider this secondary to trigger the update mechanics?