LiUSemWeb / HeFQUIN

HeFQUIN is a query federation engine for heterogeneous federations of graph data sources, including federations of knowledge graphs.
https://liusemweb.github.io/HeFQUIN/
Apache License 2.0
19 stars 3 forks source link

simplify version management #368

Closed keski closed 1 month ago

keski commented 1 month ago

In the current setup, we have to manually set the version number of each module before release. This is cumbersome and error prone. Instead, we can use:

mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false

to update the version number across all module pom files simultaneously.

The only adaptation we need to make is to drop the project.version from the properties in the main pom and use the maven default value instead (which is the same as the project version).

hartig commented 1 month ago

Great! I was already wondering how we can update the versions in all the modules without having to touch every POM file manually.

In addition to making this change in the main POM, can you please create a new Wiki page for collecting notes related to "Release Logistics" and, then, add a note about updating the version number, including the command you mention above. Additionally, the Wiki page should have notes related to the other release-related topics that came up recently (compiling the WAR, the Maven repo, the Maven dependency blob, the docker image). Later we can turn this Wiki page into a page of the Website.

keski commented 1 month ago

I've now prepared the a Release Logistics page. Please check it out to see if it looks okay and that nothing is missing.

keski commented 1 month ago

An alternative to having a changelog file in the project root would be to manage the changelog in a wiki page. But I suspect we will forget to update such a page, and keeping it as part of the feature branch feels more robust.

hartig commented 1 month ago

I've now prepared the a Release Logistics page. Please check it out to see if it looks okay and that nothing is missing.

Thanks! Good job!

A few additions:

An alternative to having a changelog file in the project root would be to manage the changelog in a wiki page. But I suspect we will forget to update such a page, and keeping it as part of the feature branch feels more robust.

Yes, I think so too.