Again a case for "autoincrement=none"

[jbennink]

Description

I read #669 and thought, yeah that is also what I need. But this has evolved in this #697 and that is not quite what I needed.

Perhaps my question is more about version numbers and how to check whether something is new in general and It might be "windows" specific. The default minver behaviour uses the tag ie "label-2.0.0" as the basis and then increments this to 2.0.1-pre0.1234 where 1234 is the commit height. This results in an assemblyversion 2.0.1.0. If your .exe checks for updates using this number and 2.0.0 is the stable then there are no updates.
But what if I want to enable giving users access to pre releases as well. Then I would somehow put the prerelease in my update server but How do I check the version number.
If I use 2.0.1.0 I have a problem once the stable 2.0.1.0 release comes around. My first thought was to include the commit height as 4th digit, ie 2.0.1.1234 but still this does not solve the "in my view logical interpretation of the numbers".

Thats why I thought #669 was a solution. By setting the autoincrement to "none" minver would generate 2.0.0-pre0.1234 instead. And the assemblyversion would be 2.0.0.1234 This could be easily interpretaed as an update after the stable 2.0.0 release (assemblyversion 2.0.0.0) and once stable 2.0.1 comes around (assemblyversion 2.0.1.0) this will still update any prerelease versions.

General question: Does anyone know of a good backend solution for updates. Currently we a running our own that accounts for enabling updates per customer, and even per computer (seat) at a customer location to be able to fine grain deploy/enable updates.

P.S. @adamralph If this is way beyond the scop of minver and/or this issue tracker please say so. I am looking around for and update mechanism that works well with git versioning (minver) and we are current investigating msixbundles and the .appinstaller mechanism which seems wofully inadequate and undocumented.

[adamralph]

@jbennink I'm not entirely sure I understand your question, but I'll try and paraphrase it:

I am performing updates by comparing the AssemblyVersion in two .NET assemblies. When I produce a pre-release version, the pre-release identifiers are not represented in the AssemblyVersion, so my update mechanism fails. What can I do instead?

Assuming that my paraphrasing is correct, I'll attempt to answer the question:

Given that pre-release versions are a series of dot-seperated alphanumeric identifiers, there is no good way to embed them in an AssemblyVersion. Therefore I recommend that you find some other way to compare your .NET assemblies, such as AssemblyInformationalVersion, which should contain the entire version, or the name of a containing package, zip file, etc.

Regarding your more general question, yes, I believe that is outside the scope of MinVer and I suggest you raise that elsewhere.

I'm closing this for now, since I do not see any feature request here, and I fail to see any connection with #669 and #667. If you would like to request a feature, please use the template. If you would like discuss anything further, please start a discussion.

[jbennink]

@adamralph I was perhaps explaining too much. The feature #669 with a "none" setting would make using prereleases with an automatic update system easier. Current any prerelease increment the patch version. So a stable 2.0.0 release generates a 2.0.1 (minver) pre-release. I have included the commit height as a 4th digit in the assemblyversion. But then 2.0.1.1234 is a prerelease for the stable 2.0.1 release.
With autoincrement=none the prerelease version would become 2.0.0.1234 and once a stable new release with be created when you tag a 2.0.1 it would generate an assemblyversion 2.1.1.0 since it will be the last commit.

In that way (with autoincrment=none) the update check of the msixbundle mechanism (https://github.com/Microsoft/msix-packaging) would still work. The current way minver autoincrements does not work.

I have also thought about useing a different field but it feel logical to use the assemblyversion as it is strongly typed and the Informational version would require scanning strings to get things to work.

BUT: I have though af a different solution for the time being, I will create two appid's and keep the prerelease versions seperate. That will also allow to install side by side and also seems to be what others do.

Thanks for you answer and keep this closed. :-)