Skip to content

Release process

This page describes how FedMS releases happen.

Living process

The release cadence and the exact tooling for FedMS are still being formalized as the framework approaches a 1.0. This page captures the current state.

Versioning

FedMS uses semantic versioning at the component level. Each component module (fedms/federation, fedms/content, fedms/task, fedms/eca, fedms/attachment, fedms/locale, fedms/scripts) versions independently.

The profile (fedms/profile) is the integration point — its version typically reflects the framework as a whole.

Current version (per fedms.info.yml): 0.9.0 — pre-1.0.

Branching model

Every FedMS repo follows the same branching model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
       ┌─ tags ─┐
       │  1.0.0 │
       │  0.9.1 │
       │  0.9.0 │
       └────────┘
           ▲
           │
       main / release branches
           ▲
           │
       develop ◄──────── feature/fix branches
  • develop is the default branch. All MRs target it.
  • Tagged releases are cut from develop (or a short-lived release branch).
  • main reflects the latest stable.

How a release happens

Component module release

  1. Open the module repo.
  2. Ensure develop is green and includes the changes you want to ship.
  3. Bump the version in fedms_X.info.yml.
  4. Update CHANGELOG.md (if the repo has one).
  5. Commit and push.
  6. Tag the release:
1
2
l3d git tag -a 1.2.3 -m "Release 1.2.3"
l3d git push origin 1.2.3
  1. The Composer registry picks up the tag automatically.

Profile release

The profile release follows the same flow, plus updating composer.json to pin the required component versions.

Recipe release

Same flow. Recipes are tagged independently.

Composer registry

All fedms/* packages are published to the group-level Composer registry at:

1
https://gitlab.lakedrops.com/api/v4/group/fedms/-/packages/composer/

The registry indexes both tagged releases and dev-* branches. Tenant composer.json files typically use:

1
2
3
"require": {
  "fedms/profile": "^0.9||dev-develop"
}

…which prefers the latest tagged release but accepts the bleeding edge from develop during active development.

Deployment to tenant sites

On managed SaaS, the LakeDrops operations team handles deployments. The typical flow:

  1. A tenant deployment pipeline runs nightly.
  2. It runs l3d composer update to pick up the latest framework versions.
  3. It runs l3d ahoy fedms update-config to apply any imperative-config updates.
  4. It runs the Playwright smoke tests against the live URL.
  5. If smoke tests pass, the deployment is finalized; if they fail, it rolls back.

The deployment-test framework is being formalized at fedms/components/profile#20.

Changelog conventions

Components that have a CHANGELOG.md follow the Keep a Changelog format:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
## [Unreleased]
### Added
- ...

### Changed
- ...

### Fixed
- ...

## [1.2.3] - 2026-01-15
### Added
- New `fedms_task_pattern_check_user_X_group_role` condition plugin.

Breaking changes

When a release introduces a breaking change:

  • Bump the major version.
  • Document the breaking change prominently in the changelog.
  • Provide an upgrade path — a hook_update_N or an Ahoy command that migrates existing tenants.
  • Open a tracking issue and link from the changelog.

Breaking changes should be rare before 1.0 (this is a pre-1.0 framework) and very rare after.

Pre-release versions

For pre-release tags, use the semver pre-release format:

1
2
3
1.0.0-rc.1
1.0.0-rc.2
1.0.0

Tenant-specific releases

Tenant sites are versioned independently from the framework. They typically don't use semantic versioning — instead they tag releases by date or by milestone (e.g. 2025-Q4).

Next steps