Switch to Nextcloud-major-aligned versioning starting at 34.0.0
Build package / package (push) Successful in 55s
Build package / php-lint (8.2) (push) Successful in 40s
Build package / php-lint (8.3) (push) Successful in 43s
Build package / php-lint (8.4) (push) Successful in 35s
Build package / php-lint (8.5) (push) Successful in 35s
Build package / xml-lint (push) Successful in 11s
Build package / unit-tests (push) Successful in 36s
Build package / package (push) Successful in 55s
Build package / php-lint (8.2) (push) Successful in 40s
Build package / php-lint (8.3) (push) Successful in 43s
Build package / php-lint (8.4) (push) Successful in 35s
Build package / php-lint (8.5) (push) Successful in 35s
Build package / xml-lint (push) Successful in 11s
Build package / unit-tests (push) Successful in 36s
Leading version number now tracks the supported Nextcloud major (currently 34, i.e. Hub 26 Spring) instead of an independent 0.x count, so compatibility is visible at a glance. Documents the scheme in CLAUDE.md's release process section.
This commit is contained in:
@@ -109,6 +109,8 @@ There is no meaningful way to test the Deck integration itself outside a real Ne
|
||||
|
||||
### Release process
|
||||
|
||||
**Versioning scheme (from 34.0.0 on): `<nextcloud-major>.<minor>.<patch>`.** The leading number tracks the minimum/maximum Nextcloud major version declared in `appinfo/info.xml`'s `<dependencies><nextcloud .../>` (currently `min-version="34" max-version="34"`), not this app's own feature history - so it only changes when the supported Nextcloud major changes (e.g. dropping/adding NC 34 support bumps to `35.0.0`), and resets `minor`/`patch` to `0.0` at that point. Ordinary fixes/features within the same supported NC major bump `minor`/`patch` as usual (semver-ish, without a leading `0.`). Versions before `34.0.0` (`0.1.x`/`0.2.x`) predate this scheme.
|
||||
|
||||
1. Bump `<version>` in `appinfo/info.xml` and `version` in `package.json` (keep them in sync).
|
||||
2. Commit, push to `main`, confirm the run of `.gitea/workflows/build-main.yml` is green.
|
||||
3. `git tag vX.Y.Z && git push origin vX.Y.Z` — this triggers the tag branch of the same workflow, which re-runs the checks, builds the frontend, runs `make appstore`, and attaches `workflow_deck_automation.tar.gz` as the asset on a normal (non-pre-) release for that tag.
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ This app lets every user configure their own Deck automation workflows from Pers
|
||||
|
||||
A background job periodically evaluates all enabled workflows and moves cards whose due date has passed, using Deck's own internal PHP classes only (no HTTP/OCS calls).
|
||||
]]></description>
|
||||
<version>0.2.3</version>
|
||||
<version>34.0.0</version>
|
||||
<licence>agpl</licence>
|
||||
<author mail="patrick@niebel.ing">Patrick Niebeling</author>
|
||||
<namespace>WorkflowDeckAutomation</namespace>
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "workflow_deck_automation",
|
||||
"version": "0.2.3",
|
||||
"version": "34.0.0",
|
||||
"private": true,
|
||||
"type": "module",
|
||||
"description": "Automates moving overdue Deck cards between stacks, configurable per user.",
|
||||
|
||||
Reference in New Issue
Block a user