Feature Request: First-class Named Version References and Published Version API

[taiebot]

Tip

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

---

Is your feature request related to a problem? Please describe.
Nextcloud Server already provides powerful file versioning, including immutable versions and named versions. However, named versions are only preserved snapshots and are not exposed as first-class resources that applications can reference through stable APIs or URLs.

As a result, applications that need approval, publishing, or release workflows must implement their own logic for managing versions. There is currently no server-side concept of a "published" or "approved" version that remains stable while users continue editing the working copy.

This limits the ability for applications such as Collectives, Text, Office, or third-party apps to build review and publishing workflows on top of the existing versioning system.

Describe the solution you'd like
Extend the existing versioning system by allowing named versions (or server-managed aliases to immutable versions) to be exposed through WebDAV and/or OCS APIs as first-class resources.

For example, a file could have references such as:

published
stable
approved
v1.0
Release-2026

These references would point to immutable versions already managed by the server and could be updated to newer approved versions without changing the reference itself.

Applications could then:

List available named version references.
Resolve a named reference to its associated immutable version.
Create or update named references.
Assign permissions so only authorized users can promote a version to a published reference.

This builds on the existing version infrastructure rather than introducing a separate publishing system.

Describe alternatives you've considered
Applications can currently implement their own publishing workflows by duplicating files, creating separate "published" folders, or maintaining custom metadata and version mappings.

However, these approaches duplicate functionality that already exists in the server, are inconsistent across applications, and make it difficult to share a common approval workflow.

Another option would be for every app to implement its own publishing API, but this fragments the ecosystem and prevents interoperability between applications.

Providing this capability at the server level would allow all applications to leverage the same versioning and approval mechanism.

Additional context
This proposal is intended as a general server capability rather than an application-specific feature.

One motivating use case is Collectives, where collaborative documents often need an approval process before changes become visible to readers. Instead of exposing the latest draft, applications could reference a stable "published" version while editors continue working on the next revision. See nextcloud/collectives#2308

The same capability would also benefit documentation systems, collaborative editing, CMS-style workflows, knowledge bases, and any application that needs review, approval, or release management.

Conceptually, this is similar to Git tags or release branches, where a stable reference points to an immutable revision while development continues independently. The proposal does not seek to replicate Git, but to expose Nextcloud's existing versioning capabilities in a way that enables similar publishing workflows across the ecosystem.

Automation and Webhooks

An additional benefit of introducing first-class named version references is that they become meaningful lifecycle events that other systems can react to.

For example, when a user promotes a document to a published or approved version, Nextcloud Server could emit an event (and optionally trigger a webhook or Flow integration).

This would enable workflows such as:

Automatically rebuilding a static documentation website.

Publishing documentation to an external portal.

Sending notifications to reviewers or stakeholders.

Synchronizing approved documents with another system.

Triggering CI/CD pipelines for documentation or configuration files.

Starting archival or compliance workflows.

Creating PDFs or other exported formats from the approved version.

Because the event originates from the server rather than an individual application, any Nextcloud app—or external system—could subscribe to the same lifecycle event.

For example:

Draft edited
│
▼
Reviewer approves
│
▼
Named reference "published" updated
│
├── Webhook
├── Nextcloud Flow
├── Activity event
├── Notification
└── External automation

This would make the feature much more than a document approval mechanism. It would establish a standard server-side publishing event that applications and integrations could build upon, enabling consistent automation across the entire Nextcloud ecosystem.

A small mockup from my feature request in collectives