Release 5.0-beta

[LinusDietz]

🎉

[koppor]

Please remove -Pdev=true from the gradle build - or add another workflow, which builds on the branch release only. (I had the latter in mind to have a reusable branch)

[koppor]

We should finish #5676 first to include some fixes in the database handling code, too.

[tobiasdiez]

@koppor I'm ok with merging #5676 asap. We can improve the build script / github actions also later after the release of 5.0 beta.

[LinusDietz]

I was wondering what benefits the end users actually have from #5676?

[koppor]

Maybe, the PDev=true thing can be "fixed" by an environment variable somehow? Maybe not.

[koppor]

@LinusDietz The sync duplicated all local entries in some cases. Did not state that in the title of the PR but came out while working on the tests.

[LinusDietz]

Maybe, the PDev=true thing can be "fixed" by an environment variable somehow? Maybe not.

yep, working on it.

[tobiasdiez]

I think

jabref/build.gradle

Line 755 in ea5e632

return project.version

needs to be changed to include beta / alpha etc

[koppor]

project.version should be 5.0-beta - shouldn't it? Like it was at the alpha version.

Refs https://github.com/JabRef/jabref/pull/5684/files#r352285359

I did not notice that we have a new thing here. In 5.0 alpha, we could just put 5.0-alpha here. See 0c342bd. Back in the install4j-times, we just had a different version number threeDotVersion, which we handled separatetly. The enabled us to cope with a) custom JabRef versioning (which is not semantic versioning) and b) versioning required by external tooling.

[Siedlerchr]

We just have to specify which version string the installer should pick (it must be numeric)

[koppor]

We should not leave the tag available more than a few minutes in case it is not used. Maybe use the tag "v5.0-beta-test-20191203" or something like that. There might be automatic tooling available checking for releases. In case the tag is changed, it might confuse users.

See https://help.github.com/en/github/receiving-notifications-about-activity-on-github/watching-and-unwatching-releases-for-a-repository for an example for notifications.

I am ware that with our new setup (#5312), the release procedure changed and we need to work on it. - It would be good to have it transparent to the user that we work on the release. Moreover, changing git tags leads to difficulties: https://stackoverflow.com/q/8432953/873282

Thank you for keep working on releasing JabRef 5.0 beta and diving into the hard things of end user-facing software: making a release! 🎉

[koppor]

I merged master, removed the tag v5.0-beta (as I assume this was broken) and added a new tag v5.0-beta-test. If that tag is good, we can creat a tag v5.0-beta, can't we?

[koppor]

Refs GitTools/GitVersion#1649

[koppor]

Maybe releasing only works for the master branch.

[tobiasdiez]

It should work now on master with the tag 5.0-beta.
The important thing is that
https://github.com/JabRef/jabref/blob/master/GitVersion.yml#L10
needs to be changed directly before a release / tag (because otherwise the build version does not increase) and that
https://github.com/JabRef/jabref/blob/master/GitVersion.yml#L8
is changed accordingly before and after a release (for example before a stable release it should set to be empty, and afterwards it should be set to alpha)

[koppor]

I found out we need SemVer in the tag: v5.0.1-beta Tobias Diez <notifications@github.com> schrieb am Fr., 13. Dez. 2019, 11:56:

…

It should work now on master with the tag 5.0-beta. The important thing is that https://github.com/JabRef/jabref/blob/master/GitVersion.yml#L10 needs to be changed directly before a release / tag (because otherwise the build version does not increase) and that https://github.com/JabRef/jabref/blob/master/GitVersion.yml#L8 is changed accordingly before and after a release (for example before a stable release it should set to be empty, and afterwards it should be set to alpha) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5684?email_source=notifications&email_token=AAKNU7QIEW36HIJPXJ2JPQ3QYNS7NA5CNFSM4JS7VC3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGZUUHA#issuecomment-565398044>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKNU7WDMKGVCIJYOKM2UW3QYNS7NANCNFSM4JS7VC3A> .

[tobiasdiez]

Why is this? The last tag on master was v5.0-alpha and it worked, right?

[koppor]

By using GitVersion, we introduced SemanticVersioning in JabRef somehow. Our 5.0 alpha was a release. 5.0 beta will be another release. In SemVer, two releases must have different version numbers. So, using 5.0.0 for both 5.0-alpha and 5.0-beta does not make sence to me.

One could argue that our alpha rlease was not a release in the sense of SemVer and that it is perfectly fine with SemVer to use 5.0.0 for both alpha and beta as both are not full releases.

[Siedlerchr]

We could argue that it was pre-release.

[tobiasdiez]

We still don't use semantic versioning. The SemVer field produced by GitVersion is not used. We only use AssemblySemVer, which does not use the patch information but instead the number of commits since the last tag (weighted so that it keeps increasing).

To important point is that you can simply take the current installer files and publish them as a release. (If you want add a tag).

[koppor]

According to the comment #5684 (comment), I created 1e9d247. Hope, this is correct. I am not sure which number to set - as we might release a beta-2.

[koppor]

In the chat, I was notified, that I had to revert that commit as no change in that file is necessary any more (at least for alpha and beta releases)