Increase build number for each commit to master

[tobiasdiez]

The MSI installer needs an increase in the version to properly upgrade a previous installation (otherwise you could end up with two installations in different locations).

There are a few tools that provide such a functionality based on the git commit (i.e GitVersion WeightedPreReleaseNumber). Maybe it's also a good moment to switch to semantic versioning?

[koppor]

Wow, https://github.com/GitTools/GitVersion#--------gitversion looks really awesome.

I, however, think that we will release a new major version all times, because the user interface behaves differently. Alternatives, we will have debates on how semver works for tools.

Maybe, we can use the tool internally, but keep on our major minor versioning scheme.

More reading: use it in github workflow: https://octopus.com/blog/versioning-with-github-actions

[LyzardKing]

The releases from master, not being "stable" releases, if we want to consider the term..
could be set by git describe --tags
so it'll put together the latest tag plus the hash of the latest tag, to keep a different version number without having to create a different thing.
For example, in another project I have the main version set to "19.06" also as a git tag. So that will be the version one sees if they install the "stable" version. If they install from github releases or git clone/any other more up to date means they'll see "19.06-20-g0170bc3"
Not elegant, but it clearly states that they are different versions, and identifies the stable from the dev one.

[tobiasdiez]

That is a good idea but sadly does not work as the msi installer expects a version of the form 1.2.3.4 (with everything being numbers).

[LyzardKing]

From the man page:
i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.

So the 20 after the proper version is an incremental number of commits, you could cut that.
So it would give a proper indication of the version also relative to the stable release (although jabref would be at v5.0.0-277 now)

EDIT Actually the tag names are different, so it would be: v5.0-alpha-277 (but the "alpha" could be removed from future tags)

For example:
git describe --tags | cut -d"-" -f1,3 | sed 's/-/./g' → v5.0.277

[koppor]

We need to create different MSI installer filenames, too. This would fix https://discourse.jabref.org/t/downloading-the-snapshot-from-today-2019-10-17-fails/1775/3 with our current upload infrastructure.

[Siedlerchr]

But we still need to have symlink in the form jabref-latest-master-windows.msi to the latest snapshot then, because otherwise this is is not useful for people who uses wget or any other tool to automatically fetch the latest version.
Didn't we had this before already?

[koppor]

@Siedlerchr You refer to the long discussion at #5312, especially #5312 (comment).

Also refs #5398.

[tobiasdiez]

With the latest update of jpackage, this issue has now increased priority as trying to install a dev version although a dev version is already installed results in the following:

Thus, the user has to manually deinstall the previous version.

@koppor This also means that if we release now a 5.0.0 (beta) the full release needs to have at least 5.0.1 as version number.