fix: remove model.api.version

[rsynek]

Fixes #2516.

Also, removed the SDK version from metadata (and keep only the Solver version).

See also: https://github.com/TimefoldAI/timefold-solver-enterprise/pull/791

The API version is now defined by the timefold.application.version in the pom.xml. The maven property is used to define a model descriptor classifier, e.g. timefold-pickup-delivery-routing-descriptor-1.2.0-v1.zip. Thus, it must be defined in pom.xml and not in the application.properties, where it gets injected by the Quarkus maven plugin.

The service-parent pom.xml defines the default value v1, which can be overridden in the model pom.xml.

The user must not override the value in application.properties, which may lead to the model being updated to the new version, but its model descriptor classifier still being v1.

[Copilot]

Pull request overview

This PR removes the model.api.version configuration/property and standardizes API versioning on timefold.application.version, while also removing the SDK version from generated model build metadata to keep only the Solver version.

Changes:

• Update tests and config overrides to read timefold.application.version instead of model.api.version.
• Replace model.api.version with timefold.application.version in model build/publishing metadata (POM classifier, Quarkus build properties, container image naming).
• Update documentation to describe versioning and REST path prefixing in terms of timefold.application.version and remove model.api.version from the quickstart.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
service/test-model/src/test/java/ai/timefold/solver/model/testmodel/OpenApiTest.java	Switch OpenAPI test to use timefold.application.version for file path and path-prefix assertions.
service/test-model/src/test/java/ai/timefold/solver/model/testmodel/EmployeeScheduleResourceTest.java	Use timefold.application.version for REST base path and SSE client calls; fix OperationOnPost import location.
service/test-model/src/test/java/ai/timefold/solver/model/testmodel/ApiVersion2ConfigProfile.java	Update test profile override key to timefold.application.version.
service/test-model/src/main/resources/application.properties	Remove model.api.version from test-model config.
service/service-defaults/src/main/resources/application.properties	Remove version defaulting from model.api.version and update container image naming to use timefold.application.version.
service/quarkus/deployment/src/main/java/ai/timefold/solver/service/quarkus/deployment/TimefoldModelDescriptorProcessor.java	Remove SDK version from generated ModelBuildInfo payload.
service/facade/service-parent/pom.xml	Replace model.api.version Maven property with timefold.application.version and pass it into Quarkus build properties/classifier.
service/definition/src/main/java/ai/timefold/solver/service/definition/internal/descriptor/ModelBuildInfo.java	Drop sdkVersion field from build-info record.
docs/src/modules/ROOT/pages/running-timefold-solver/service/rest-api.adoc	Update REST API versioning docs to reference timefold.application.version.
docs/src/modules/ROOT/pages/quickstart/service/getting-started.adoc	Remove model.api.version from quickstart config and adjust REST path explanation to use timefold.application.version.

Comments suppressed due to low confidence (1)

docs/src/modules/ROOT/pages/quickstart/service/getting-started.adoc:256

• The quickstart no longer shows how to set the required timefold.application.version, which can cause builds to fail (and the later REST API section assumes it is set).

# Application metadata — included in the generated OpenAPI specification
timefold.application.name=my-model
timefold.application.contact.email=info@example.com
timefold.application.contact.name=Your Name
timefold.application.contact.url=https://example.com

[triceo]

LGTM. Although you may want to rebase to see if the CI failures went away.

[mswiderski]

I assume it is still possible to change the version from command line as it used to be, right? I used it quite often when working with maven plugin deployments.

[rsynek]

I assume it is still possible to change the version from command line as it used to be, right? I used it quite often when working with maven plugin deployments.

Yes, it just needs to be changed as a maven property, so e.g.:

mvn clean install -Dtimefold.application.version=v2

[Copilot]

🟡 Not ready to approve

service-defaults still configures quarkus.rest.path via ${model.api.version} while the build now injects timefold.application.version, which risks removing the API version prefix at runtime.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Comments suppressed due to low confidence (2)

docs/src/modules/ROOT/pages/quickstart/service/getting-started.adoc:266

• The quickstart now references timefold.application.version in REST path examples but does not state where that version is configured, which may confuse readers after removing model.api.version from application.properties.

`timefold.application.name` and the contact fields are *required* metadata.
They are used to identify your service, validate the JSON schema of requests, and populate the generated OpenAPI specification.

service/facade/service-parent/pom.xml:600

• The Quarkus Maven plugin now only injects timefold.application.version, but service-defaults still sets quarkus.rest.path from ${model.api.version}, which will drop the API version prefix at runtime when model.api.version is absent.

              <properties>
                <timefold.application.version>${timefold.application.version}</timefold.application.version>
              </properties>

• Files reviewed: 10/10 changed files
• Comments generated: 0 new
• Review effort level: Low

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

The REST API documentation still lists demo-data endpoints as /v<version>/... despite the configured version value already including the v prefix, which makes the examples inconsistent with the described /{timefold.application.version}/demo-data path.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Comments suppressed due to low confidence (1)

docs/src/modules/ROOT/pages/running-timefold-solver/service/rest-api.adoc:102

• The demo-data endpoint bullets use /v<version>/... even though the configured version value already includes the v prefix (for example timefold.application.version=v1), which implies a doubled v and contradicts the preceding /{timefold.application.version}/demo-data description.

These are *not* nested under `<root>`: the path is `/{timefold.application.version}/demo-data`, not `/<root>/demo-data`.
For example, with `timefold.application.version=v1` this is `/v1/demo-data`.

- `GET /v<version>/demo-data`: Retrieve all available demo dataset ids.
- `GET /v<version>/demo-data/\{demoDataId\}`: Retrieve the demo dataset with the given identifier

• Files reviewed: 10/10 changed files
• Comments generated: 0 new
• Review effort level: Low

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

The quickstart and REST API docs still leave gaps/ambiguity around timefold.application.version being required and being configured via Maven (not application.properties), which can mislead users.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Comments suppressed due to low confidence (2)

docs/src/modules/ROOT/pages/quickstart/service/getting-started.adoc:266

• The quickstart now says only timefold.application.name and contact fields are required, but timefold.application.version is also required (and no longer set in application.properties), so readers may not know how to satisfy the build-time validation; update this paragraph to mention timefold.application.version and that it should be set via the Maven property in pom.xml.

`timefold.application.name` and the contact fields are *required* metadata.
They are used to identify your service, validate the JSON schema of requests, and populate the generated OpenAPI specification.

docs/src/modules/ROOT/pages/running-timefold-solver/service/rest-api.adoc:89

• The REST API guide explains changing the API version via the Maven property, but it doesn’t explicitly warn against overriding timefold.application.version in application.properties, which can desync the runtime REST prefix from the model descriptor classifier; amend the NOTE to state it must be set in pom.xml (not application.properties).

NOTE: To change the API version, override the `timefold.application.version` Maven property in the `pom.xml`.
The Quarkus property of the same name gets configured automatically from the Maven property.

• Files reviewed: 10/10 changed files
• Comments generated: 0 new
• Review effort level: Low

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud