Versioning & Build

Independent versioning

Lino projects can contain multiple services and web applications. Each deployable item has its own version, so a small fix in one service does not force an artificial release of the entire system. This is important in modular and distributed architectures, where APIs, workers, web apps, migrations, and integration contracts can evolve at different speeds.

The operational version is stored in a simple text file named version.txt. For services, the file is located at src/Services/<ServiceName>/version.txt. For web applications, it is located at src/WebApps/<WebAppName>/version.txt. The Lino CLI reads these files when listing, showing, bumping, and generating versioned builds.

SemVer rule used by Lino

MAJOR.MINOR.PATCH

• PATCH increments the last number and should be used for compatible fixes, small internal improvements, and changes that do not alter the public contract.
• MINOR increments the middle number and resets patch to zero. Use it for backward-compatible features, new endpoints, optional fields, or additive behavior.
• MAJOR increments the first number and resets minor and patch. Use it when consumers need to adapt, for example because an API contract changed incompatibly or a behavior was intentionally replaced.

Examples: 1.0.0 can represent the first stable version, 1.0.1 a compatible fix, 1.1.0 a new compatible capability or new endpoints without breaking changes, and 2.0.0 a release with changes that require clients to update.

Inspect current versions

Use lino version list to see the current versions of all services and web applications in the project:

lino version list

Use lino version show when you need to inspect the version of a specific service or web application. The command asks whether the target is a service or a web application and displays the version read from the corresponding version.txt file.

lino version show

Bump a version

Use lino version bump when a service or web application is ready for a new release:

lino version bump

1. Run the command from the project root.
2. Select one or more services or web applications. The prompt shows each item with its current version.
3. Choose the increment type: patch, minor, or major.
4. Confirm the answers. Lino updates the selected version.txt files and displays a table with the new versions.

Each execution keeps a clear change trail, improves consistency with release practices, and makes alignment with CI/CD pipelines easier. The version number stops being a loose detail and starts identifying the deployable artifact that actually changed.

Version changes should be reviewed together with the technical impact of the release. A database migration may be tied to a service version, API consumers may need contract notes, and integration events may require compatibility checks. Keeping the version close to the deployable item makes these decisions explicit and easier to audit.

Before a major increment, review public APIs, event contracts, migrations, client compatibility, and external consumers. Before a minor increment, confirm that the new behavior is additive. Before a patch, confirm that the change is compatible and does not change usage expectations.

Build and containerization

In the videos and in daily development, dotnet build is used frequently to validate that the generated solution still compiles after each modeling step. The lino build command has another purpose: to prepare selected services and web applications for release by publishing them in Release mode with the .NET container publish profile.

This separation avoids treating a simple compilation validation as a delivery package. Use dotnet build during development to find errors early. Use lino build when the artifact is ready to receive a version, become a container image, and move to a registry or deployment pipeline.

What lino build does

Run the command from the root of a Lino project:

lino build

The CLI validates the authenticated user and the current project configuration, asks which services or web applications should be included in the build, and then asks whether the version should be kept or incremented. When an increment is selected, Lino updates the corresponding version.txt before generating the build commands.

The backend returns the exact commands to run. Currently, these commands use dotnet publish with -c Release, -p:PublishProfile=DefaultContainer, -p:ContainerRepository, -p:ContainerImageTag, and -p:ContainerLabelVersion. The image tag and the container version label receive the same SemVer value chosen for the release.

In practice, the process compiles the service or web application code, applies the required publish configuration, generates a container image based on the current SemVer version, and assigns standardized name, tag, and metadata to the artifact.

Generated repository names

Lino normalizes project and item names to generate predictable container repositories:

• Simple service API: <project-name>/services/<service-name>-api:1.2.3
• Modular service host: <project-name>/services/<service-name>-host:1.2.3
• Blazor web application: <project-name>/webapps/<webapp-name>:1.2.3

This convention keeps service APIs, modular hosts, and web applications separated in the registry, preserving the release version in the tag. The pattern also eliminates repetitive manual decisions and reduces divergence between environments, CI/CD scripts, and operational documentation.

Publishing to registries

Generated images can be published to the registry used by your deployment platform:

• Docker Hub
• GitHub Container Registry
• AWS ECR
• Azure Container Registry
• any other OCI-compatible registry.

Whenever possible, deploy by pointing to immutable version tags, such as 1.2.3, instead of floating tags. This improves rollback, auditing, and comparison between what was built, published, and deployed.

Recommended release workflow

1. Run the project tests and dotnet build to validate the source code before packaging.
2. Check current versions with lino version list and review which services or web applications changed.
3. Use lino build and choose whether the current version will be kept or receive a patch, minor, or major increment.
4. Publish the generated container images to the registry used by the deployment platform, such as Docker Hub, GitHub Container Registry, AWS ECR, Azure Container Registry, or another compatible registry.
5. Deploy by referencing traceable version tags and keep changelog, migrations, and rollback plan connected to the same release.

Do not put secrets, production connection strings, or environment-specific credentials inside the generated images. Use environment variables, user secrets for local development, CI/CD secret vaults, or the deployment platform secret mechanism.

With this flow, versioning and build stay connected: the same SemVer value recorded in the project is used as the container tag and as release metadata, improving traceability between source code, migrations, API contracts, integration events, and deployed artifacts.