Goal
Consistently name the legacy ownCloud server product ownCloud Classic across all user-facing documentation in the owncloud and owncloud-docker organisations. The version (10, or soon 11) is applied only as additional information where relevant — e.g. "ownCloud Classic 10".
The new product, ownCloud Infinite Scale (oCIS), must never be renamed.
Canonical naming rule
| From |
To |
ownCloud Server, owncloud Server (product sense) |
ownCloud Classic |
ownCloud Classic Server, Classic Server |
ownCloud Classic |
ownCloud 10 / ownCloud 11 |
ownCloud Classic 10 / ownCloud Classic 11 |
OC10 / oc10 (prose shorthand only) |
ownCloud Classic |
Never touch: ownCloud Infinite Scale, Infinite Scale, oCIS, ocis; xref:/include:: targets; module slugs (classic_ui, oc10-app); URLs/paths; anchors/IDs; inline code/literals; and the generic "a server running ownCloud" instance sense (not a product-name use).
Scope
Documentation / user-facing text only (.adoc, .md, READMEs, release notes, website copy). Source code, identifiers, and xref targets are out of scope. Translation files (*.po/*.pot) are a separate downstream follow-up.
Process per repo
branch docs/rebrand-owncloud-classic → apply ruleset (space-containing patterns are inherently prose-only; they cannot match URLs/slugs which contain no spaces) → review oc10 shorthand by hand → verify (URL/xref targets byte-identical, oCIS count unchanged, docs build introduces no new errors) → signed commit → PR titled docs: normalize legacy server product name to "ownCloud Classic".
Repositories
Tier A — docs repos
Tier B — code repos with embedded docs (docs files only)
owncloud-docker org
Optional follow-up (Phase 4)
Introduce a server-product-name: ownCloud Classic attribute in this repo's global-attributes.yml (fetched at build time) so future drift is prevented. Literal-string replacement (this campaign) comes first; attribute substitution in .adoc is a later, separate stage.
Backports to maintained version branches
Re-derived per branch (content drift made cherry-pick infeasible); same ruleset, verified per branch (targets byte-identical, oCIS unchanged, build error-set unchanged where buildable).
docs-main, docs-webui, docs (aggregate) publish from a single branch — no backport needed. Archived x_archived_* branches are intentionally left untouched.
Goal
Consistently name the legacy ownCloud server product ownCloud Classic across all user-facing documentation in the
owncloudandowncloud-dockerorganisations. The version (10, or soon 11) is applied only as additional information where relevant — e.g. "ownCloud Classic 10".The new product, ownCloud Infinite Scale (oCIS), must never be renamed.
Canonical naming rule
ownCloud Server,owncloud Server(product sense)ownCloud ClassicownCloud Classic Server,Classic ServerownCloud ClassicownCloud 10/ownCloud 11ownCloud Classic 10/ownCloud Classic 11OC10/oc10(prose shorthand only)ownCloud ClassicNever touch:
ownCloud Infinite Scale,Infinite Scale,oCIS,ocis;xref:/include::targets; module slugs (classic_ui,oc10-app); URLs/paths; anchors/IDs; inline code/literals; and the generic "a server running ownCloud" instance sense (not a product-name use).Scope
Documentation / user-facing text only (
.adoc,.md, READMEs, release notes, website copy). Source code, identifiers, and xref targets are out of scope. Translation files (*.po/*.pot) are a separate downstream follow-up.Process per repo
branch docs/rebrand-owncloud-classic→ apply ruleset (space-containing patterns are inherently prose-only; they cannot match URLs/slugs which contain no spaces) → reviewoc10shorthand by hand → verify (URL/xref targets byte-identical, oCIS count unchanged, docs build introduces no new errors) → signed commit → PR titleddocs: normalize legacy server product name to "ownCloud Classic".Repositories
Tier A — docs repos
Tier B — code repos with embedded docs (docs files only)
owncloud-docker org
Optional follow-up (Phase 4)
Introduce a
server-product-name: ownCloud Classicattribute in this repo'sglobal-attributes.yml(fetched at build time) so future drift is prevented. Literal-string replacement (this campaign) comes first; attribute substitution in.adocis a later, separate stage.Backports to maintained version branches
Re-derived per branch (content drift made cherry-pick infeasible); same ruleset, verified per branch (targets byte-identical, oCIS unchanged, build error-set unchanged where buildable).
docs-main, docs-webui, docs (aggregate) publish from a single branch — no backport needed. Archived
x_archived_*branches are intentionally left untouched.