When you install a application in Windows, the application must have a version in the form major.minor.patch, and that match semver. But what do I do with eg. version 1.1.3-rc1
We must have some way of have numerical version numbers for pre-releases.
One (bad) option is not to allow any pre-release for patches and increase the patch version for each pre-release.
semver
internal version
1.8.0-rc1
1.8.0
1.8.0-rc2
1.8.1
1.8.0-rc3
1.8.2
1.8.3
1.8.3
I don't like it, it is strange. But how should I do?
Originally created by @magol on GitHub (Sep 21, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/332
When you install a application in Windows, the application must have a version in the form major.minor.patch, and that match semver. But what do I do with eg. version 1.1.3-rc1
We must have some way of have numerical version numbers for pre-releases.
One (bad) option is not to allow any pre-release for patches and increase the patch version for each pre-release.
| semver | internal version |
| --- | --- |
| 1.8.0-rc1 | 1.8.0 |
| 1.8.0-rc2 | 1.8.1 |
| 1.8.0-rc3 | 1.8.2 |
| 1.8.3 | 1.8.3 |
I don't like it, it is strange. But how should I do?
Can't you just use 1.8.0 for all of them? I mean, the main version part is still 1.8.0 and only the pre-release identifier, which Windows doesn't support, changes. Or do these versions have to increment?
<!-- gh-comment-id:248657693 -->
@FichteFoll commented on GitHub (Sep 21, 2016):
Can't you just use `1.8.0` for all of them? I mean, the main version part is still `1.8.0` and only the pre-release identifier, which Windows doesn't support, changes. Or do these versions have to increment?
But, if I install 1.8.0-rc2 with version number 1.8.0 and then install 1.8.0-rc3 also with version number 1.8.0, do Windows see any difference between the versions?
Unless I misunderstood something, MSI will see it as I'm trying to install the same version that I already have with strange results as a consequence. We have in any case not got it to work when we tested.
<!-- gh-comment-id:248829196 -->
@magol commented on GitHub (Sep 22, 2016):
But, if I install 1.8.0-rc2 with version number 1.8.0 and then install 1.8.0-rc3 also with version number 1.8.0, do Windows see any difference between the versions?
Unless I misunderstood something, MSI will see it as I'm trying to install the same version that I already have with strange results as a consequence. We have in any case not got it to work when we tested.
What about fourth (build) number for internal version? Something like this
semver
internal version
1.8.0-rc1
1.8.0.1
1.8.0-rc2
1.8.0.2
1.8.0-rc3
1.8.0.3
1.8.0
1.8.0.4
<!-- gh-comment-id:283591655 -->
@lvv83 commented on GitHub (Mar 2, 2017):
What about fourth (build) number for internal version? Something like this
semver | internal version
------------ | -------------
1.8.0-rc1 | 1.8.0.1
1.8.0-rc2 | 1.8.0.2
1.8.0-rc3 | 1.8.0.3
1.8.0 | 1.8.0.4
@lvv83 Great suggestion, but I do think that MSI only care about three numbers :-(
<!-- gh-comment-id:283596887 -->
@magol commented on GitHub (Mar 2, 2017):
@lvv83 Great suggestion, but I do think that MSI only care about three numbers :-(
Well, MSI ProductVersion is incompatible with semver cause it use major.minor.build format (no prereleases). Also it has constraints like maximum value of 255 for major and minor, 65535 for build.
So, we need for some new rule, which translates semver to MSI ProductVersion and vice versa.
We can combine patch and prerelease numbers from semver to the MSI build number. But first we need to replace semver with appropriate internal version.
semver
internal version
msi version
1.8.0-rc1
1.8.0.1
1.8.1
1.8.0-rc2
1.8.0.2
1.8.2
1.8.0-rc3
1.8.0.3
1.8.3
1.8.0
1.8.0.4
1.8.4
1.8.1-rc1
1.8.1.1
1.8.1001
1.8.1-rc2
1.8.1.2
1.8.1002
internal format is "X.Y.Z.N";
msi_build = Z * 1000 + N
<!-- gh-comment-id:283624749 -->
@lvv83 commented on GitHub (Mar 2, 2017):
Well, MSI [ProductVersion](https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx) is incompatible with semver cause it use `major.minor.build` format (no prereleases). Also it has constraints like maximum value of **255** for `major` and `minor`, **65535** for `build`.
So, we need for some new rule, which translates semver to MSI ProductVersion and vice versa.
We can combine patch and prerelease numbers from semver to the MSI build number. But first we need to replace semver with appropriate internal version.
semver | internal version | msi version
------------ | ------------- | -------------
1.8.0-rc1 | 1.8.0.1 | 1.8.1
1.8.0-rc2 | 1.8.0.2 | 1.8.2
1.8.0-rc3 | 1.8.0.3 | 1.8.3
1.8.0 | 1.8.0.4 | 1.8.4
1.8.1-rc1 | 1.8.1.1 | 1.8.1001
1.8.1-rc2 | 1.8.1.2 | 1.8.1002
```
internal format is "X.Y.Z.N";
msi_build = Z * 1000 + N
```
Cuando instala una aplicación en Windows, la aplicación debe tener una versión con el formato major.minor.patch y que coincida con semver. Pero, ¿qué hago con eg. versión 1.1.3-rc1
Debemos tener alguna forma de tener números de versión numéricos para las versiones preliminares.
Una (mala) opción es no permitir ningún prelanzamiento para parches y aumentar la versión del parche para cada prelanzamiento.
semver versión interna
1.8.0-rc1 1.8.0
1.8.0-rc2 1.8.1
1.8.0-rc3 1.8.2
1.8.3 1.8.3
No me gusta, es extraño. Pero, ¿cómo debo hacer?
Buscar archivos de mi nube
<!-- gh-comment-id:442770612 -->
@711216 commented on GitHub (Nov 29, 2018):
> Cuando instala una aplicación en Windows, la aplicación debe tener una versión con el formato major.minor.patch y que coincida con semver. Pero, ¿qué hago con eg. versión 1.1.3-rc1
>
> Debemos tener alguna forma de tener números de versión numéricos para las versiones preliminares.
>
> Una (mala) opción es no permitir ningún prelanzamiento para parches y aumentar la versión del parche para cada prelanzamiento.
>
> semver versión interna
> 1.8.0-rc1 1.8.0
> 1.8.0-rc2 1.8.1
> 1.8.0-rc3 1.8.2
> 1.8.3 1.8.3
> No me gusta, es extraño. Pero, ¿cómo debo hacer?
Buscar archivos de mi nube
I don't understand your referenced link @grv87, he is not using it for product.
@magol there are 4 numbers available for a version number within EXE & DLLs.
And how do you encode alpha, beta, pre... (are there others?)
<!-- gh-comment-id:493112075 -->
@jaques-sam commented on GitHub (May 16, 2019):
I don't understand your referenced link @grv87, he is not using it for product.
@magol there are 4 numbers available for a version number within EXE & DLLs.
And how do you encode alpha, beta, pre... (are there others?)
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?
<!-- gh-comment-id:642143631 -->
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing :fireworks: Did you find any consensus?
@alexandrtovmach commented on GitHub (Jun 14, 2021):
Closing as staled, feel free to re-open or create a new issue 👻
<!-- gh-comment-id:860357226 -->
@alexandrtovmach commented on GitHub (Jun 14, 2021):
Closing as staled, feel free to re-open or create a new issue :ghost:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @magol on GitHub (Sep 21, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/332
When you install a application in Windows, the application must have a version in the form major.minor.patch, and that match semver. But what do I do with eg. version 1.1.3-rc1
We must have some way of have numerical version numbers for pre-releases.
One (bad) option is not to allow any pre-release for patches and increase the patch version for each pre-release.
I don't like it, it is strange. But how should I do?
@FichteFoll commented on GitHub (Sep 21, 2016):
Can't you just use
1.8.0for all of them? I mean, the main version part is still1.8.0and only the pre-release identifier, which Windows doesn't support, changes. Or do these versions have to increment?@magol commented on GitHub (Sep 22, 2016):
But, if I install 1.8.0-rc2 with version number 1.8.0 and then install 1.8.0-rc3 also with version number 1.8.0, do Windows see any difference between the versions?
Unless I misunderstood something, MSI will see it as I'm trying to install the same version that I already have with strange results as a consequence. We have in any case not got it to work when we tested.
@lvv83 commented on GitHub (Mar 2, 2017):
What about fourth (build) number for internal version? Something like this
@magol commented on GitHub (Mar 2, 2017):
@lvv83 Great suggestion, but I do think that MSI only care about three numbers :-(
@lvv83 commented on GitHub (Mar 2, 2017):
Well, MSI ProductVersion is incompatible with semver cause it use
major.minor.buildformat (no prereleases). Also it has constraints like maximum value of 255 formajorandminor, 65535 forbuild.So, we need for some new rule, which translates semver to MSI ProductVersion and vice versa.
We can combine patch and prerelease numbers from semver to the MSI build number. But first we need to replace semver with appropriate internal version.
@magol commented on GitHub (Mar 2, 2017):
I like this solution. But it is strange that the numbers go from 4 to 1001.
@lvv83 commented on GitHub (Mar 2, 2017):
You can use any rule for msi build number. Yet one without strange gaps.
@711216 commented on GitHub (Nov 29, 2018):
Buscar archivos de mi nube
@jaques-sam commented on GitHub (May 16, 2019):
I don't understand your referenced link @grv87, he is not using it for product.
@magol there are 4 numbers available for a version number within EXE & DLLs.
And how do you encode alpha, beta, pre... (are there others?)
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?
@alexandrtovmach commented on GitHub (Jun 14, 2021):
Closing as staled, feel free to re-open or create a new issue 👻