Prepare next-dev phase 24.0.0-SNAPSHOT #359
Conversation
JIRA: LIGHTY-394 Signed-off-by: Peter Suna <[email protected]>
Summary of ChangesHello @PeterSuna, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request prepares the "lighty-yang-validator" project for its next development cycle by updating the project version across key configuration and documentation files. This ensures that all references to the project's development snapshot version are consistent, facilitating a smooth transition into the "24.0.0-SNAPSHOT" phase. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request prepares for the next development phase by updating the project version to 24.0.0-SNAPSHOT. The changes correctly update the version in pom.xml, README.md, and a Java source file. My review focuses on improving maintainability by removing hardcoded version strings. I've suggested changes in README.md to make the instructions version-agnostic and recommended a way to load the version from pom.xml in the Java code to avoid manual updates in the future. These changes will make future version bumps easier and less error-prone.
As a minor point, the title in README.md still refers to version 23. You might want to update that as well for consistency.
| ``` | ||
|
|
||
| The distribution will be stored in the **"target"** directory, as a file called *lighty-yang-validator-23.0.0-SNAPSHOT-bin.zip* | ||
| The distribution will be stored in the **"target"** directory, as a file called *lighty-yang-validator-24.0.0-SNAPSHOT-bin.zip* |
There was a problem hiding this comment.
Hardcoding the version in the filename makes the documentation require manual updates for each release, which is error-prone. Consider using a more generic description that doesn't need to change with every version bump.
| The distribution will be stored in the **"target"** directory, as a file called *lighty-yang-validator-24.0.0-SNAPSHOT-bin.zip* | |
| The distribution will be stored in the **"target"** directory, as a file called *lighty-yang-validator-<version>-bin.zip*. |
|
|
||
| ``` | ||
| unzip lighty-yang-validator-23.0.0-SNAPSHOT-bin.zip | ||
| unzip lighty-yang-validator-24.0.0-SNAPSHOT-bin.zip |
There was a problem hiding this comment.
Hardcoding the version in this command requires manual updates for each release. Using a wildcard would make the command more robust across versions and less prone to documentation errors.
| unzip lighty-yang-validator-24.0.0-SNAPSHOT-bin.zip | |
| unzip lighty-yang-validator-*-bin.zip |
| private final ArgumentParser lyvArgumentParser = ArgumentParsers.newFor("LYV").build() | ||
| .defaultHelp(true) | ||
| .version("Version: ${prog} 23.0.0-SNAPSHOT\nContact: [email protected]") | ||
| .version("Version: ${prog} 24.0.0-SNAPSHOT\nContact: [email protected]") |
There was a problem hiding this comment.
Hardcoding the version string here creates a maintenance burden, as it needs to be manually updated for each release. This is error-prone, as it can be easily forgotten.
A better approach would be to fetch the version from the pom.xml at build time. You could, for example:
- Create a properties file (e.g.,
version.properties) insrc/main/resourceswith content likeversion=${project.version}. - Ensure resource filtering is enabled in your
pom.xmlfor this file. - Load this properties file at runtime to get the version string.
This would ensure the version is always in sync with the project's version defined in pom.xml.
1 participant
JIRA: LIGHTY-394