V1.4 release

[christian-rli]

Closes #22 #32 #54 #57

[Ludee]

Perfect, all issues considered. Ready to merge from my side.
We decided to gice a new version number, since there are multiple version of v1.4 now.
So this one would be v1.4.1 or v1.5!?

[Bachibouzouk]

So this one would be v1.4.1 or v1.5!?

@Ludee, @christian-rli Side note on the release format: I would stick with "three digit" release number format, i.e. v1.5.0 in case it should be v1.5. This reference guide for semantic versioning could also help answer your question.

[christian-rli]

I would go with either using 1.4.0 or, based on the recommendations in the reference guide linked by @Bachibouzouk , 2.0.0. It's tricky. My reason for both options is, that there was no real 1.4.0 before.

I realize that there are strings compatible with an almost complete version 1.4.0. But 1.4.0 was never declared complete and it's not clear that they conform to the same version of the string (I would assume they don't). There would be a weird gap of versions, because what is 1.4.0 then? Why isn't there a function to convert from it? It's been codenamed 1.4 all along would just need to be declared "done" now.

2.0.0, could make sense, because if we create a new version number, this would reflect not being downwards-compatible to 1.3.0.

[Ludee]

I would favour:
"metadataVersion": "OEP-1.4.0"

All unofficial versions were labelled "1.4" and can be updated easily.

[christian-rli]

I would favour:
"metadataVersion": "OEP-1.4.0"

All unofficial versions were labelled "1.4"

Clever! Let's just stick with "metadataVersion": "OEP-1.4.0" then.

[Ludee]

Final changes are added to all three files!

[Ludee]

Checked and Liked!