Produktentwicklung / Versionen

Konventionen

Installer-Dateien

Die Haupt-Installer-Datei (welche installOrUpgrade aufruft) sollten wie folgt benannt sein:

• ou.sp.$PRODUKTKÜRZEL.installer.ts

Sollten verlinkte Schritte notwendig sein (Testbarkeit, Übersichtlichtkeit), sollten diese wie folgt benannt sein:

• ou.sp.$PRODUKTKÜRZEL.installer.runner.ts - Script, welches die einzelnen Subtasks aufruft, sofern nötig (kann auch in der ou.sp.$PRODUKTKÜRZEL.installer.ts implementiert werden)
• ou.sp.$PRODUKTKÜRZEL.installer.step.$BESCHREIBUNG.ts - Subtask

Update-Dateien

Update-Dateien sollten wie folgt benannt sein:

• ou.sp.$PRODUKTKÜRZEL.installer.update.$VERSION.ts - Die Version muss hierbei natürlich mit der Version, zu der das Update gehört, gleich sein.

Sollten mehrere Features oder Fixes mit einer Version hereinkommen, welche ein Update-Script benötigen, so muss dies in der Update-Datei sichtbar sein. Beispielsweise über nach Issue-ID (z.B. POM-123) benannte Step-Funktionen:

import type { InstallStepInputOptions } from "@one-unity/library/ou.sp.Package";
const { Package } = require("ou.sp.Library");

function pom123(options: InstallStepInputOptions): void {
    options.appendToResultSuccess("testing 123...");
}

function inv456(options: InstallStepInputOptions): void {
    options.appendToResultSuccess("testing 456...");
}

module.exports = Package.createInstallerModule(
    [
        { id: "POM-123", execute: pom123 },
        { id: "INV-456", execute: inv456 },
    ],
    { message: "Applying update X.Y.Z", asUser: "oucadmin" }
);

Neue Update-Dateien (Version NEXT)

Bei neuen Update-Dateien, bei denen die neue Version noch nicht klar ist, muss wie folgt benannt werden:

• ou.sp.$PRODUKTKÜRZEL.installer.update.next.ts

In der ou.sp.$PRODUKTKÜRZEL.installer.ts muss {{VERSION_NEXT}} als Placeholder verwendet werden:

...
updateScriptsJs: [{
    version: "{{VERSION_NEXT}}",
    updateScriptName: "ou.sp.$PRODUKTKÜRZEL.installer.update.{{VERSION_NEXT}}"
}],
...

Versionsplatzhalter

{{VERSION_NEXT}} ist ein Platzhalter für die nächste Versionsnummer. Er wird je nach Pakettyp und Build-Modus unterschiedlich ersetzt. $VERSION steht dabei jeweils für die in der package.json des Pakets hinterlegte Version:

Inhaltsersetzung

Lösungen (z.B. invoice, postman, library)

Modus	Verzeichnis	Dateitypen	Was wird ersetzt
Develop-Build	build/, dist/	*.js, *.jsp, *.sql, *.less, INSTALL.md, Workflow-ext/config/*.xml	{{VERSION_NEXT}} → $MAJOR.$MINOR.999; .update.next" → .update.$MAJOR.$MINOR.999"
Release-PR	src/	*.installer.ts (nur updateScriptsJs-Block), *.next.ts, *.next.test.ts, *.next.test.ts.snap, *next.sql	{{VERSION_NEXT}} → $VERSION; .update.next" → .update.$VERSION"

Dokumentationen (z.B. invoice-docs, postman-docs, library-docs)

Modus	Verzeichnis	Dateitypen	Was wird ersetzt
Develop-Build	build/	*.json, *.html, *.js	{{VERSION_NEXT}} → $MAJOR.$MINOR.999; {{!VERSION_NEXT}} → {{VERSION_NEXT}} (Kaskade, s.u.)
Release-PR	docs/	*.md, *.mdx	{{VERSION_NEXT}} → $VERSION

Umbenennung von Dateien

Lösungen (z.B. invoice, postman, library)

Modus	Verzeichnis	Dateien
Develop-Build	dist/	*.next.js → *.$MAJOR.$MINOR.999.js
Release-PR	src/	*.next.ts → *.$VERSION.ts, *.next.test.ts → *.$VERSION.test.ts, *.next.test.ts.snap → *.$VERSION.test.ts.snap, *next.sql → *$VERSION.sql

Dokumentationen (z.B. invoice-docs, postman-docs, library-docs)

Modus	Verzeichnis	Dateien
Develop-Build	build/	Ordner namens {{VERSION_NEXT}} → $MAJOR.$MINOR.999
Develop-Build	build/diffs/	next.patch → $MAJOR.$MINOR.999.patch
Release-PR	static/diffs/	next.patch → $VERSION.patch
Release-PR	docs/	next.md → $VERSION.md, next.mdx → $VERSION.mdx

Escape-Mechanismus (nur Dokumentationen)

Soll {{VERSION_NEXT}} selbst als lesbarer Text erscheinen (nicht ersetzt werden), wird ein weiteres ! vorangestellt: {{!VERSION_NEXT}}. Das Muster kaskadiert — jedes ! reduziert sich im Build-Artefakt um eins.