In the near future i’ll introduce a strict versionscheme on how to name them. Here are the details and why.Okay first lets talk about how Delphinus handles versions right now. When a package is loaded (from Github), it requests the list of existing releases. For each existing release it uses the tag-name and adds it as version to the package. But the Version is still just a string and always handled like this. So far so good, we have a list of Versions and can use it to select one for download at a later time.
But how does Delphinus compare those versions then? How does it detect if an update is available? In short: it doesn’t! For each installed Package, it searches the corresponsding online package and checks if the most recent Versionstring is different form the currently installed. For this small usecase it works. But something that will hit me in the future:
- To actually compare two versions whe need the complete VersionHistory, find the Index of a Version and compare those
- What do we do if we have no VersionHistory?
- WHat if (in future versions) we try to compare the same package from different sources with incomplete Versionhistories?
The solution: Delphinus will actually parse the tag-name to calculate a Version. It will look similar (but maybe not the same) to Nuget-Versions (Which are similar to SemVer, but not the same). The formatting is like this:
Major.Minor.Patch-PreReleaseLabel
PrereleaseLabel is optional and only for Unstable releases (stable ones do NOT have a PreReleaseLabel).
Example
1.2.3
1.2.3-Beta
1.2-Alpha
The first version contains normal Major, Minor, Patch and is consideres stable as it has no Label. The other two do have labels and are considered unstable. IMPORTANT: The dash (‘-‘) after the final digit is mandatory if you specify a PreReleaseLabel. Otherwhise everything after the last digit is ignored!
Example
1.2.3Beta
This is internally stored as 1.2.3 and Beta is ommitted. This one is consideres stable!
To not break compatibility with existing tags, the parser ignores everything until it hits the first digit (0-9).
Example
Foo-1.2.3
This is internally stored as 1.2.3 and “foo” is simply ignored.
How does Delphinus compare the Numbers? For this it follows a similar mechanic to Nuget:
- Compare Major, Minor, Patch as usual
- If both versions are equal up to this level, do a TextCompare (not casesensitive) between the PreReleaseLabels
- A an empty PreReleaseLabel has a higher value than any other Label, so stables are always on top of unstables
The Textcompare between these Labels is important to keep in mind, since numbers added to the labels are still treated as strings!
Example
1.0.0-Alpha2
1.0.0-Alpha03
In this case Alpha2 is higher(!) than Alpha03 even if Alpha03 is meant to be AFTER Alpha2.
All of this is currently in a featurebranch feature/StrictVersionScheme. This branch contains a new project called VerScheme.dproj. It is a commandline tool to help you test Versionstrings. Give it one parameter and it will print out the information. Give it two parameters and it will compare them and display the result.
I have updated the wiki on Versioning your package
Those rules are not yet enforced but will be! Invalid versions are not lost (if you ever create one) but can not get checked for updates or other things correctly!