Checks version skip, pending DB upgrade, occ update:check status, and
non-shipped app compatibility (with an apps.nextcloud.com fallback
lookup) to verify if it looks safe to upgrade to the next Nextcloud major
version.
Checks version skip, pending DB upgrade, occ update:check status, and
non-shipped app compatibility (with an apps.nextcloud.com fallback
lookup) to verify if it looks safe to upgrade to the next Nextcloud major
version.
There definitely should be a standard way to do this with abra - I remember some discussion, but as far as I know, this is not done yet.
Did you create the script using any LLMs? Then I propose to add the disclaimer from https://git.coopcloud.tech/c4dt/ai-policy (self-promotion...)
I'm not sure it makes sense to change the release-notes after the tag is created. Perhaps for later tags, but if somebody upgrades to tag 13.2.0, I think the release notes will not show.
I'm not sure it makes sense to change the release-notes after the tag is created. Perhaps for later tags, but if somebody upgrades to tag 13.2.0, I think the release notes will not show.
dannygroenewegen marked this conversation as resolved
And a minor nitpick: I like my .md files hard-wrapped and every new sentence on a new line. This makes later diffs more readable. Would you agree to run prettier on your changes?
And a minor nitpick: I like my `.md` files hard-wrapped and every new sentence on a new line. This makes later diffs more readable. Would you agree to run `prettier` on your changes?
Checks version skip, pending DB upgrade, occ update:check status, and
non-shipped app compatibility (with an apps.nextcloud.com fallback
lookup) to verify if it looks safe to upgrade to the next Nextcloud major
version.
Is this for 13.2.1 or 14.0.0? I propose the latter, so we can keep 13.2.0 finished. But I don't have any hard opinion on this one.
Agree, next release is fine. Doesn't need to be released on its own.
> Is this for 13.2.1 or 14.0.0? I propose the latter, so we can keep 13.2.0 finished. But I don't have any hard opinion on this one.
Agree, next release is fine. Doesn't need to be released on its own.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Checks version skip, pending DB upgrade, occ update:check status, and
non-shipped app compatibility (with an apps.nextcloud.com fallback
lookup) to verify if it looks safe to upgrade to the next Nextcloud major
version.
There definitely should be a standard way to do this with abra - I remember some discussion, but as far as I know, this is not done yet.
Did you create the script using any LLMs? Then I propose to add the disclaimer from https://git.coopcloud.tech/c4dt/ai-policy (self-promotion...)
@@ -196,0 +224,4 @@return 1ficurrent_version=$(echo "$status_json" | php -r '$d=json_decode(stream_get_contents(STDIN),true); echo $d["versionstring"] ?? "";')is
jqavailable in the docker image? That would make this nicer...Unfortunately, jq is not available.
@@ -1 +1,2 @@Last release for nextcloud-32, pointing to the latest version of nextcloud-32.Last release for nextcloud-32.I'm not sure it makes sense to change the release-notes after the tag is created. Perhaps for later tags, but if somebody upgrades to tag 13.2.0, I think the release notes will not show.
And a minor nitpick: I like my
.mdfiles hard-wrapped and every new sentence on a new line. This makes later diffs more readable. Would you agree to runprettieron your changes?Is this for 13.2.1 or 14.0.0? I propose the latter, so we can keep 13.2.0 finished. But I don't have any hard opinion on this one.
f866496870to2fb279d96aAgree, next release is fine. Doesn't need to be released on its own.