Parent: #70
Depends on: #78, #82
Blocks: #71, #74, #75, #76
Goal
Provide the reusable version/channel state model for prereleases and final releases.
Nightly builds remain separate and are out of scope.
Incremental output
Completion of this issue adds the reusable Version / ReleaseChannel / transition-policy capability to the PHP tool.
These domain objects become direct dependencies of #71/#74/#75; later issues must not reimplement version parsing or prerelease transitions.
Channels
State transitions
Transitions are explicit and deterministic. Examples:
16.0.0-alpha.2 + alpha → 16.0.0-alpha.3
16.0.0-alpha.3 + beta → 16.0.0-beta.1
16.0.0-beta.2 + rc → 16.0.0-rc.1
16.0.0-rc.3 + rc → 16.0.0-rc.4
16.0.0-rc.4 + final → 16.0.0
Repeated beta increments must likewise be deterministic.
Invalid backwards channel transitions are rejected unless an explicit recovery policy is later added.
Explicit version override
An override is allowed only if consistent with:
- selected branch/release line;
- current version;
- requested channel;
- existing tags/releases;
- no version regression.
It does not bypass validation.
New major line
A new stable line may begin from development/prerelease metadata already present in the consumer's version source.
Do not reject -dev, alpha, beta or RC simply because there is no prior final tag for that major.
The app major is consumer data; do not assume app major equals Nextcloud major.
Nextcloud App Store behavior
Alpha/beta/RC releases use the normal app release flow with the prerelease suffix in the app version.
Do not mark alpha/beta/RC releases as App Store nightly builds. The official Nextcloud release process explicitly distinguishes prereleases from nightlies; the suffix is the prerelease signal.
GitHub Release mapping
Expose whether the selected channel should set GitHub's prerelease flag.
- alpha/beta/rc → prerelease;
- final → non-prerelease.
Milestone integration
Expose enough channel state for #74 to select a consumer-configured prerelease vs normal patch milestone policy.
Acceptance criteria
- versions parsed/compared independently of GitHub;
- alpha → beta → rc → final covered;
- repeated alpha/beta/RC increments covered;
- invalid regressions rejected;
- final removes prerelease suffix without inventing another major;
- GitHub prerelease state exposed;
- nightly remains independent.
Definition of done
Parent: #70
Depends on: #78, #82
Blocks: #71, #74, #75, #76
Goal
Provide the reusable version/channel state model for prereleases and final releases.
Nightly builds remain separate and are out of scope.
Incremental output
Completion of this issue adds the reusable
Version/ReleaseChannel/ transition-policy capability to the PHP tool.These domain objects become direct dependencies of #71/#74/#75; later issues must not reimplement version parsing or prerelease transitions.
Channels
State transitions
Transitions are explicit and deterministic. Examples:
Repeated beta increments must likewise be deterministic.
Invalid backwards channel transitions are rejected unless an explicit recovery policy is later added.
Explicit version override
An override is allowed only if consistent with:
It does not bypass validation.
New major line
A new stable line may begin from development/prerelease metadata already present in the consumer's version source.
Do not reject
-dev, alpha, beta or RC simply because there is no prior final tag for that major.The app major is consumer data; do not assume app major equals Nextcloud major.
Nextcloud App Store behavior
Alpha/beta/RC releases use the normal app release flow with the prerelease suffix in the app version.
Do not mark alpha/beta/RC releases as App Store nightly builds. The official Nextcloud release process explicitly distinguishes prereleases from nightlies; the suffix is the prerelease signal.
GitHub Release mapping
Expose whether the selected channel should set GitHub's prerelease flag.
Milestone integration
Expose enough channel state for #74 to select a consumer-configured prerelease vs normal patch milestone policy.
Acceptance criteria
Definition of done