refactor: centralize version management in project by koi2000 · Pull Request #2797 · apache/hugegraph
Improved version management by introducing Maven's property
Replaced hardcoded version strings with dynamic retrieval
Added version.properties to support runtime version access
Purpose of the PR
This PR centralizes version management across the project by leveraging Maven's ${revision} property and a filtered version.properties file for dynamic runtime access to the version. It removes the need for hardcoded version strings and ensures consistent versioning across all modules.
Summary With CN
- 新功能
- 引入 version.properties 文件，实现版本号和相关属性的集中配置，通过属性文件动态获取版本信息。
- 功能优化
- 多处组件（如 API、Core、RPC、PD 服务等）和启动脚本中的版本号由硬编码改为从属性文件动态读取，提升了版本管理的灵活性和一致性。
- API 版本兼容性检查范围改为动态读取属性，便于后续维护。
- API 文档配置改为程序化构建，增强了安全配置的灵活性。
- 构建与依赖
- Maven 配置优化，资源文件支持过滤，依赖版本号采用变量引用，便于统一管理和升级。
- 脚本改进
- 启动脚本根据属性文件动态加载版本号，避免手动修改脚本中的版本信息。
Main Changes
Replaced hardcoded version strings in classes like CommonVersion, RpcVersion, CoreVersion, and API.
Added a version.properties file with resource filtering for dynamic version retrieval.
Updated startup scripts (start-pd.sh, start-store.sh) to reflect the new version.
Remove the @OpenAPIDefinition annotation and specify the version in OpenAPI in the code instead.
Verifying these changes
- Trivial rework / code cleanup without any test coverage. (No Need)
- Already covered by existing tests, such as (please modify tests here).
- Need tests and can be verified as follows:
- Update the revision in Maven, rebuild the project, and check if the version matches.
Does this PR potentially affect the following parts?
- Dependencies (add/update license info & regenerate_known_dependencies.sh)
- Modify configurations
- The public API
- Other affects (typed here)
- Nope
Documentation Status
-
Doc - TODO -
Doc - Done -
Doc - No Need
labels
Jun 11, 2025
This comment was marked as outdated.
This comment was marked as outdated.
imbajin
changed the title
centralize version management
refactor: centralize version management in project
This comment was marked as outdated.
This comment was marked as outdated.
| HOME_DIR=$(pwd) | ||
| PD_DIR=$HOME_DIR/hugegraph-pd/apache-hugegraph-pd-incubating-1.5.0 | ||
|
|
||
| PROPERTIES_FILE="$HOME_DIR/hugegraph-commons/hugegraph-common/src/main/resources/version.properties" |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By referencing the version.properties file in hugegraph-commons using a relative path, considering that start-pd.sh and start-store.sh are currently only used in the CI environment, maybe acceptable for now...
@imbajin What do you think?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By referencing the
version.propertiesfile inhugegraph-commonsusing a relative path, considering thatstart-pd.shandstart-store.share currently only used in the CI environment, maybe acceptable for now...@imbajin What do you think?
It seems so. We can make adjustments if we encounter any problems?
The version number in the pom.xml in the root directory of the project seems to have been forgotten? see https://github.com/apache/incubator-hugegraph/blob/master/pom.xml#L89
Currently, version management mainly relies on the ${revision} variable in the flatten-maven-plugin. When updating the version, the ${revision} variable must be updated. The Version property in version.properties will be replaced with the ${revision} value from the POM file during compilation.
Additionally, when updating the version, it may also be necessary to update other fields in version.properties, such as ApiCheckBeginVersion and ApiCheckEndVersion, which are responsible for version validity checks. When hugegraph-commons is updated, the hugegraph-commons.version in the POM file may also need to be updated.
@koi2000 I would like to confirm if we upgrade the version of hugegraph to 1.9, we need to modify the following files:
diff --git a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties index b413bf04e..1ef0cba5a 100644 --- a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties +++ b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties @@ -19,5 +19,5 @@ Version=${revision} ApiVersion=0.71 ApiCheckBeginVersion=1.0 -ApiCheckEndVersion=1.7 -VersionInBash=1.5.0 +ApiCheckEndVersion=2.0 +VersionInBash=1.9.0 diff --git a/hugegraph-commons/pom.xml b/hugegraph-commons/pom.xml index 09cd71e5a..df3337dd1 100644 --- a/hugegraph-commons/pom.xml +++ b/hugegraph-commons/pom.xml @@ -90,7 +90,7 @@ <properties> <!-- Note: We need also update the version in CommonVersion.java & RpcVersion.java now --> - <revision>1.5.0</revision> + <revision>1.9.0</revision> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <top.level.dir>${project.basedir}/..</top.level.dir> <compiler.source>1.8</compiler.source> diff --git a/pom.xml b/pom.xml index 1fa07660e..fa98ec7a4 100644 --- a/pom.xml +++ b/pom.xml @@ -86,8 +86,8 @@ </scm> <properties> - <revision>1.5.0</revision> - <hugegraph-commons.version>1.5.0</hugegraph-commons.version> + <revision>1.9.0</revision> + <hugegraph-commons.version>1.9.0</hugegraph-commons.version> <lombok.version>1.18.30</lombok.version> <release.name>hugegraph</release.name> <maven.compiler.source>11</maven.compiler.source>
if this aligns with the design expectations?
@koi2000 I would like to confirm if we upgrade the version of hugegraph to 1.9, we need to modify the following files:
diff --git a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties index b413bf04e..1ef0cba5a 100644 --- a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties +++ b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties @@ -19,5 +19,5 @@ Version=${revision} ApiVersion=0.71 ApiCheckBeginVersion=1.0 -ApiCheckEndVersion=1.7 -VersionInBash=1.5.0 +ApiCheckEndVersion=2.0 +VersionInBash=1.9.0 diff --git a/hugegraph-commons/pom.xml b/hugegraph-commons/pom.xml index 09cd71e5a..df3337dd1 100644 --- a/hugegraph-commons/pom.xml +++ b/hugegraph-commons/pom.xml @@ -90,7 +90,7 @@ <properties> <!-- Note: We need also update the version in CommonVersion.java & RpcVersion.java now --> - <revision>1.5.0</revision> + <revision>1.9.0</revision> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <top.level.dir>${project.basedir}/..</top.level.dir> <compiler.source>1.8</compiler.source> diff --git a/pom.xml b/pom.xml index 1fa07660e..fa98ec7a4 100644 --- a/pom.xml +++ b/pom.xml @@ -86,8 +86,8 @@ </scm> <properties> - <revision>1.5.0</revision> - <hugegraph-commons.version>1.5.0</hugegraph-commons.version> + <revision>1.9.0</revision> + <hugegraph-commons.version>1.9.0</hugegraph-commons.version> <lombok.version>1.18.30</lombok.version> <release.name>hugegraph</release.name> <maven.compiler.source>11</maven.compiler.source>if this aligns with the design expectations?
You may also need to update the revision in the pom file under hugegraph-commons, or use a command similar to the following during the build: mvn package -DskipTests -Drevision=1.9.0 -ntp
In terms of design, I have only removed the hard-coded version information in the code. Perhaps it would be worth trying to move all version information into the POM file in the root directory for management. However, I have not found a suitable solution, as the fields in the compiled version.properties file cannot be read by start-pd.sh and start-store.sh. Therefore, the VersionInBash hard-coded value has been retained in version.properties.
Should I modify the current solution?
@koi2000 I would like to confirm if we upgrade the version of hugegraph to 1.9, we need to modify the following files:
diff --git a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties index b413bf04e..1ef0cba5a 100644 --- a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties +++ b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties @@ -19,5 +19,5 @@ Version=${revision} ApiVersion=0.71 ApiCheckBeginVersion=1.0 -ApiCheckEndVersion=1.7 -VersionInBash=1.5.0 +ApiCheckEndVersion=2.0 +VersionInBash=1.9.0 diff --git a/hugegraph-commons/pom.xml b/hugegraph-commons/pom.xml index 09cd71e5a..df3337dd1 100644 --- a/hugegraph-commons/pom.xml +++ b/hugegraph-commons/pom.xml @@ -90,7 +90,7 @@ <properties> <!-- Note: We need also update the version in CommonVersion.java & RpcVersion.java now --> - <revision>1.5.0</revision> + <revision>1.9.0</revision> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <top.level.dir>${project.basedir}/..</top.level.dir> <compiler.source>1.8</compiler.source> diff --git a/pom.xml b/pom.xml index 1fa07660e..fa98ec7a4 100644 --- a/pom.xml +++ b/pom.xml @@ -86,8 +86,8 @@ </scm> <properties> - <revision>1.5.0</revision> - <hugegraph-commons.version>1.5.0</hugegraph-commons.version> + <revision>1.9.0</revision> + <hugegraph-commons.version>1.9.0</hugegraph-commons.version> <lombok.version>1.18.30</lombok.version> <release.name>hugegraph</release.name> <maven.compiler.source>11</maven.compiler.source>if this aligns with the design expectations?
You may also need to update the revision in the pom file under hugegraph-commons, or use a command similar to the following during the build: mvn package -DskipTests -Drevision=1.9.0 -ntp
In terms of design, I have only removed the hard-coded version information in the code. Perhaps it would be worth trying to move all version information into the POM file in the root directory for management. However, I have not found a suitable solution, as the fields in the compiled version.properties file cannot be read by start-pd.sh and start-store.sh. Therefore, the VersionInBash hard-coded value has been retained in version.properties. Should I modify the current solution?
Fine, compared to before, the number of files that need to be modified has been greatly reduced. The current version upgrade cost is acceptable.
@imbajin, any suggestion?
This comment was marked as outdated.
This comment was marked as outdated.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR centralizes version management across the project by replacing hardcoded version strings with dynamic retrieval from a filtered properties file and Maven’s revision property.
- Updated shell scripts (start-store.sh and start-pd.sh) to source version.properties for version management.
- Modified Java classes (CoreVersion, ApiVersion, RpcVersion, CommonVersion, API) to use a centralized VersionUtil for version retrieval.
- Added a version.properties file and updated pom.xml files to enable Maven resource filtering.
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| hugegraph-server/hugegraph-dist/src/assembly/travis/start-store.sh | Added logic to source version.properties and update directory path using version property. |
| hugegraph-server/hugegraph-dist/src/assembly/travis/start-pd.sh | Similar to start-store.sh; sources version.properties and sets the PD directory. |
| hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/version/CoreVersion.java | Replaced hardcoded version with dynamic retrieval via VersionUtil. |
| hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/version/ApiVersion.java | Updated API version retrieval and check using VersionUtil methods. |
| hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/server/ApplicationConfig.java | Revised OpenAPI configuration using a dynamically retrieved version and restructured the OpenAPI setup. |
| hugegraph-pd/hg-pd-service/src/main/java/org/apache/hugegraph/pd/rest/API.java | Updated version retrieval for the PD API. |
| hugegraph-pd/hg-pd-service/pom.xml | Updated dependency version reference to use a Maven property. |
| hugegraph-commons/hugegraph-rpc/src/main/java/org/apache/hugegraph/version/RpcVersion.java | Replaced hardcoded version with VersionUtil in RPC module. |
| hugegraph-commons/hugegraph-common/src/main/resources/version.properties | Added version.properties with version mappings and properties. |
| hugegraph-commons/hugegraph-common/src/main/java/org/apache/hugegraph/version/CommonVersion.java | Updated common version retrieval using VersionUtil. |
| hugegraph-commons/hugegraph-common/src/main/java/org/apache/hugegraph/util/VersionUtil.java | Introduced cached load for properties and added methods for API version support. |
| hugegraph-commons/hugegraph-common/pom.xml | Enabled resource filtering for version.properties. |
Comment on lines 35 to 36
| // TODO: use a flexible way to define the version | ||
| // refer: https://github.com/apache/hugegraph/pull/2528#discussion_r1573823996 |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove it?
@koi2000 I would like to confirm if we upgrade the version of hugegraph to 1.9, we need to modify the following files:
diff --git a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties index b413bf04e..1ef0cba5a 100644 --- a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties +++ b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties @@ -19,5 +19,5 @@ Version=${revision} ApiVersion=0.71 ApiCheckBeginVersion=1.0 -ApiCheckEndVersion=1.7 -VersionInBash=1.5.0 +ApiCheckEndVersion=2.0 +VersionInBash=1.9.0 diff --git a/hugegraph-commons/pom.xml b/hugegraph-commons/pom.xml index 09cd71e5a..df3337dd1 100644 --- a/hugegraph-commons/pom.xml +++ b/hugegraph-commons/pom.xml @@ -90,7 +90,7 @@ <properties> <!-- Note: We need also update the version in CommonVersion.java & RpcVersion.java now --> - <revision>1.5.0</revision> + <revision>1.9.0</revision> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <top.level.dir>${project.basedir}/..</top.level.dir> <compiler.source>1.8</compiler.source> diff --git a/pom.xml b/pom.xml index 1fa07660e..fa98ec7a4 100644 --- a/pom.xml +++ b/pom.xml @@ -86,8 +86,8 @@ </scm> <properties> - <revision>1.5.0</revision> - <hugegraph-commons.version>1.5.0</hugegraph-commons.version> + <revision>1.9.0</revision> + <hugegraph-commons.version>1.9.0</hugegraph-commons.version> <lombok.version>1.18.30</lombok.version> <release.name>hugegraph</release.name> <maven.compiler.source>11</maven.compiler.source>if this aligns with the design expectations?
You may also need to update the revision in the pom file under hugegraph-commons, or use a command similar to the following during the build: mvn package -DskipTests -Drevision=1.9.0 -ntp
In terms of design, I have only removed the hard-coded version information in the code. Perhaps it would be worth trying to move all version information into the POM file in the root directory for management. However, I have not found a suitable solution, as the fields in the compiled version.properties file cannot be read by start-pd.sh and start-store.sh. Therefore, the VersionInBash hard-coded value has been retained in version.properties. Should I modify the current solution?
@koi2000 maybe we need add a basic doc for it? (How could other devs modify the version if they need)
@koi2000 I would like to confirm if we upgrade the version of hugegraph to 1.9, we need to modify the following files:
diff --git a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties index b413bf04e..1ef0cba5a 100644 --- a/hugegraph-commons/hugegraph-common/src/main/resources/version.properties +++ b/hugegraph-commons/hugegraph-common/src/main/resources/version.properties @@ -19,5 +19,5 @@ Version=${revision} ApiVersion=0.71 ApiCheckBeginVersion=1.0 -ApiCheckEndVersion=1.7 -VersionInBash=1.5.0 +ApiCheckEndVersion=2.0 +VersionInBash=1.9.0 diff --git a/hugegraph-commons/pom.xml b/hugegraph-commons/pom.xml index 09cd71e5a..df3337dd1 100644 --- a/hugegraph-commons/pom.xml +++ b/hugegraph-commons/pom.xml @@ -90,7 +90,7 @@ <properties> <!-- Note: We need also update the version in CommonVersion.java & RpcVersion.java now --> - <revision>1.5.0</revision> + <revision>1.9.0</revision> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <top.level.dir>${project.basedir}/..</top.level.dir> <compiler.source>1.8</compiler.source> diff --git a/pom.xml b/pom.xml index 1fa07660e..fa98ec7a4 100644 --- a/pom.xml +++ b/pom.xml @@ -86,8 +86,8 @@ </scm> <properties> - <revision>1.5.0</revision> - <hugegraph-commons.version>1.5.0</hugegraph-commons.version> + <revision>1.9.0</revision> + <hugegraph-commons.version>1.9.0</hugegraph-commons.version> <lombok.version>1.18.30</lombok.version> <release.name>hugegraph</release.name> <maven.compiler.source>11</maven.compiler.source>if this aligns with the design expectations?
You may also need to update the revision in the pom file under hugegraph-commons, or use a command similar to the following during the build: mvn package -DskipTests -Drevision=1.9.0 -ntp
In terms of design, I have only removed the hard-coded version information in the code. Perhaps it would be worth trying to move all version information into the POM file in the root directory for management. However, I have not found a suitable solution, as the fields in the compiled version.properties file cannot be read by start-pd.sh and start-store.sh. Therefore, the VersionInBash hard-coded value has been retained in version.properties. Should I modify the current solution?@koi2000 maybe we need add a basic doc for it? (How could other devs modify the version if they need)
Is the repository corresponding to the documentation incubator-hugegraph-doc? I will open a PR in the documentation repository later.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters