chore: prepare next development version

[ruromero]

No description provided.

[qodo-code-review]

Review Summary by Qodo

Prepare next development version 1.4.0-SNAPSHOT

📦 Other

Walkthroughs

Description

• Update project version to 1.4.0-SNAPSHOT
• Prepare repository for next development cycle

Diagram

flowchart LR
  A["projectVersion: 1.3.0"] -- "bump to next dev" --> B["projectVersion: 1.4.0-SNAPSHOT"]

Loading

File Changes

1. gradle.properties ⚙️ Configuration changes +1/-1

Bump version to 1.4.0-SNAPSHOT

• Update projectVersion from 1.3.0 to 1.4.0-SNAPSHOT
• Mark repository as development version for next release cycle

gradle.properties

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (0)   📎 Requirement gaps (0)

🐞\ ☼ Reliability (1)

1. Release ZIP version mismatch 🐞 ☼

Description

With projectVersion now set to 1.4.0-SNAPSHOT, the tag-driven release workflow runs buildPlugin
without passing -PprojectVersion from the tag, so the built plugin version may not match the tag.
This can cause the workflow to fail when uploading the expected tag-named ZIP from
build/distributions.

Code

gradle.properties[1]

+projectVersion=1.4.0-SNAPSHOT

Evidence

The Gradle project version is sourced directly from gradle.properties projectVersion, which this PR
changes to a -SNAPSHOT value. The release workflow derives VERSION from the git tag and uses that
tag-derived VERSION in the asset_path it tries to upload, but it does not override projectVersion
when running buildPlugin, so the artifact produced can be versioned differently than the
tag/asset_path expectation.

/gradle.properties[1-3]
/build.gradle.kts[12-14]
/.github/workflows/release.yml[19-24]
/.github/workflows/release.yml[45-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The release workflow builds the plugin without forcing `projectVersion` to match the git tag, but later uploads an asset whose path/name is derived from the tag.

### Issue Context
`build.gradle.kts` sets `version` from the `projectVersion` Gradle property (from `gradle.properties` unless overridden). After this PR, that value is `*-SNAPSHOT`, which can diverge from the release tag.

### Fix Focus Areas
- /.github/workflows/release.yml[19-24]
- /build.gradle.kts[12-14]

### Suggested change
In `release.yml`, pass `-PprojectVersion=${{ steps.get_version.outputs.VERSION }}` to the `./gradlew buildPlugin` invocation (so the produced plugin/artifact version matches the tag used for the release asset name/path).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Release zip version mismatch 🐞 Bug ☼ Reliability

With projectVersion now set to 1.4.0-SNAPSHOT, the tag-driven release workflow runs buildPlugin
without passing -PprojectVersion from the tag, so the built plugin version may not match the tag.
This can cause the workflow to fail when uploading the expected tag-named ZIP from
build/distributions.

Agent Prompt

### Issue description
The release workflow builds the plugin without forcing `projectVersion` to match the git tag, but later uploads an asset whose path/name is derived from the tag.

### Issue Context
`build.gradle.kts` sets `version` from the `projectVersion` Gradle property (from `gradle.properties` unless overridden). After this PR, that value is `*-SNAPSHOT`, which can diverge from the release tag.

### Fix Focus Areas
- /.github/workflows/release.yml[19-24]
- /build.gradle.kts[12-14]

### Suggested change
In `release.yml`, pass `-PprojectVersion=${{ steps.get_version.outputs.VERSION }}` to the `./gradlew buildPlugin` invocation (so the produced plugin/artifact version matches the tag used for the release asset name/path).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud