coop-cloud/nextcloud
9
5
Fork 11
Code Issues 18 Pull Requests 11 Releases Wiki Activity

Proposing a MAINTENANCE file #81

Open
ineiti wants to merge 3 commits from ineiti/nextcloud:maintenance.md into main
pull from: ineiti/nextcloud:maintenance.md
merge into: coop-cloud:main
Conversation 12 Commits 3 Files Changed 2
+97
ineiti commented 2026-05-22 10:24:44 +00:00
Contributor
Copy Link
Copy Source

Cobbled together a file with the help of Claude.
I did re-read all of it, manually edited some parts,
and asked for modifications.

Cobbled together a file with the help of Claude. I did re-read all of it, manually edited some parts, and asked for modifications.
ineiti requested review from decentral1se 2026-05-22 10:24:52 +00:00
3wordchant commented 2026-05-28 16:44:48 +00:00
Owner
Copy Link
Copy Source

@ineiti I like the reference to Nextcloud's own release schedule!

@ineiti I like the reference to Nextcloud's own release schedule!
dannygroenewegen requested changes 2026-06-02 14:02:10 +00:00
Dismissed
MAINTENANCE.md Outdated
@@ -0,0 +31,4 @@
This recipe commits to the following, which is tighter than the floor set by
Resolution 025 (stable-recipe category):
- Respond to PRs / issues within 3 working days
dannygroenewegen commented 2026-06-02 13:33:59 +00:00
Member
Copy Link
Copy Source

I can join the maintainers team, but I cannot commit to these timelines. Can we rephrase all these deadlines to something like 'within a reasonable amount of time', or is someone else willing to commit to these timelines?

Tagging others from #57 that wanted to maintain: @stevensting @simon @Apfelwurm

I can join the maintainers team, but I cannot commit to these timelines. Can we rephrase all these deadlines to something like 'within a reasonable amount of time', or is someone else willing to commit to these timelines? Tagging others from #57 that wanted to maintain: @stevensting @simon @Apfelwurm
ineiti commented 2026-06-05 07:58:06 +00:00
Author
Contributor
Copy Link
Copy Source

I propose we keep the timeline, but add "according to best effort" or something like that. Having a timeline can also give an incentive to move the task up in the list of "voluntary project efforts". And, as none of us is paid for this, nobody will get fired over missing a deadline :)

So if we're a bunch of maintainers, I think 3 days is reasonable for a reply. Also, it's not about solving the issue, but at least advancing it a bit.

I propose we keep the timeline, but add "according to best effort" or something like that. Having a timeline can also give an incentive to move the task up in the list of "voluntary project efforts". And, as none of us is paid for this, nobody will get fired over missing a deadline :) So if we're a bunch of maintainers, I think 3 days is reasonable for a reply. Also, it's not about solving the issue, but at least advancing it a bit.
dannygroenewegen commented 2026-06-09 07:23:49 +00:00
Member
Copy Link
Copy Source

I'm not afraid of getting fired, but I do tend to take commitments seriously, so I don't want to commit to something I won't be able to keep up with. Starting this list with the fact that we aim for these deadlines is indeed a good middle ground.

I'm not afraid of getting fired, but I do tend to take commitments seriously, so I don't want to commit to something I won't be able to keep up with. Starting this list with the fact that we aim for these deadlines is indeed a good middle ground.
ineiti marked this conversation as resolved
MAINTENANCE.md Outdated
@@ -0,0 +51,4 @@
- **Patch releases (e.g. `32.0.x`)**: published to this recipe shortly after
upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer
reviews, deploys against a test instance, and tags.
dannygroenewegen commented 2026-06-02 13:47:31 +00:00
Member
Copy Link
Copy Source

If we are deploying a patch release only quickly against a test instance, I don't think that adds much value compared to the tests that Nextcloud itself already does. If the patch image update is done by Renovate, the risk of making a configuration error is pretty small.

I would propose that, for a patch release, a maintainer does a quick review (release notes and Nextcloud's issue tracker?) and then releases the new version.

A patch can always introduce a bug that affects someone, but the same patch could also fix a bug for someone else and security issues. Overall, I think it's better to have a low threshold for releasing patch updates.

The next line for Minor release should then be updated to something like a more thorough review of the release notes and a test upgrade?

If we are deploying a patch release only quickly against a test instance, I don't think that adds much value compared to the tests that Nextcloud itself already does. If the patch image update is done by Renovate, the risk of making a configuration error is pretty small. I would propose that, for a patch release, a maintainer does a quick review (release notes and Nextcloud's issue tracker?) and then releases the new version. A patch can always introduce a bug that affects someone, but the same patch could also fix a bug for someone else and security issues. Overall, I think it's better to have a low threshold for releasing patch updates. The next line for Minor release should then be updated to something like a more thorough review of the release notes and a test upgrade?
👍 1
ineiti marked this conversation as resolved
MAINTENANCE.md Outdated
@@ -0,0 +53,4 @@
upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer
reviews, deploys against a test instance, and tags.
- **Minor releases**: same flow as patch releases.
- **Major releases (e.g. `32 → 33`)**: not adopted on day one. We wait for the
dannygroenewegen commented 2026-06-02 14:00:10 +00:00
Member
Copy Link
Copy Source

Proposal for Major release:

  • Upgrade should be tested by at least two maintainers, preferably on a production-like instance, not just a fresh instance.
  • Before the Major release, we first release a new Minor version that sets the image tag for Nextcloud to e.g. nextcloud:32-fpm. This allows anyone not willing to upgrade to the next major version to stay on the current version while still getting minor and patch releases for that version. This recipe release will be less predictable; a redeploy could pull an updated Nextcloud image. If you don't want that unpredictability, you can still use the previously released recipe with a specific 32.x.x image)
  • Release the Major update with the image tag set to the latest specific release, e.g. nextcloud:33.0.2-fpm
Proposal for Major release: - Upgrade should be tested by at least two maintainers, preferably on a production-like instance, not just a fresh instance. - Before the Major release, we first release a new Minor version that sets the image tag for Nextcloud to e.g. nextcloud:32-fpm. This allows anyone not willing to upgrade to the next major version to stay on the current version while still getting minor and patch releases for that version. This recipe release will be less predictable; a redeploy could pull an updated Nextcloud image. If you don't want that unpredictability, you can still use the previously released recipe with a specific 32.x.x image) - Release the Major update with the image tag set to the latest specific release, e.g. nextcloud:33.0.2-fpm
ineiti commented 2026-06-05 08:00:12 +00:00
Author
Contributor
Copy Link
Copy Source

Can you please explain how tagging with nextcloud:32-fpm helps in that case? I'm not yet very fluent in how abra works with upgrades.

Can you please explain how tagging with `nextcloud:32-fpm` helps in that case? I'm not yet very fluent in how abra works with upgrades.
dannygroenewegen commented 2026-06-09 09:02:56 +00:00
Member
Copy Link
Copy Source

The current recipe version is 13.0.1+32.0.3-fpm, which deploys the 32.0.3-fpm image of Nextcloud. If we now decide to move to Nextcloud 33, we would release a recipe with the tagged version 14.0.0+33.0.5-fpm. But if for whatever reason you can't move to version 33 yet, you'll have to stay on recipe version 13.0.1+32.0.3-fpm, and you're missing out on all the bugfixes and security updates in 32.0.4-32.0.12. Version 32 will still receive updates for a few more months.

I'm proposing to first release a recipe version 13.1.0+32-fpm. This version will have the nextcloud image tag set to nextcloud:32-fpm. On redeploy, Docker will pull the latest 32 image (currently 32.0.12), but after a reboot it should just keep the last image version that was deployed. So a redeploy is less predictable in the sense that it could pull a new 32.x.x image if that was released since the last deploy. (To be fair, I haven't fully tested this with abra, so there might be edge cases where it will or won't pull an updated image)

Immediately after we release a recipe version 14.0.0+33.0.5-fpm with image tag nextcloud:33.0.5-fpm. So anyone just updating to the latest recipe version should not notice a difference. But if you want to stay on Nextcloud 32, you can choose between recipe 13.0.1+32.0.3-fpm for a fixed image version or recipe version 13.1.0+32-fpm to get the latest 32 image on redeploy.

The current recipe version is 13.0.1+32.0.3-fpm, which deploys the 32.0.3-fpm image of Nextcloud. If we now decide to move to Nextcloud 33, we would release a recipe with the tagged version 14.0.0+33.0.5-fpm. But if for whatever reason you can't move to version 33 yet, you'll have to stay on recipe version 13.0.1+32.0.3-fpm, and you're missing out on all the bugfixes and security updates in 32.0.4-32.0.12. Version 32 will still receive updates for a few more months. I'm proposing to first release a recipe version 13.1.0+32-fpm. This version will have the nextcloud image tag set to nextcloud:32-fpm. On redeploy, Docker will pull the latest 32 image (currently 32.0.12), but after a reboot it should just keep the last image version that was deployed. So a redeploy is less predictable in the sense that it could pull a new 32.x.x image if that was released since the last deploy. (To be fair, I haven't fully tested this with abra, so there might be edge cases where it will or won't pull an updated image) Immediately after we release a recipe version 14.0.0+33.0.5-fpm with image tag nextcloud:33.0.5-fpm. So anyone just updating to the latest recipe version should not notice a difference. But if you want to stay on Nextcloud 32, you can choose between recipe 13.0.1+32.0.3-fpm for a fixed image version or recipe version 13.1.0+32-fpm to get the latest 32 image on redeploy.
ineiti commented 2026-06-13 16:43:36 +00:00
Author
Contributor
Copy Link
Copy Source

OK, if I understand that correctly, you propose to create a "catch-all-future-updates" version, where the user can app deploy --force and it will pull the latest minor/patch version of the previous major version. Sounds like a good hack! Thanks for the explanation.

OK, if I understand that correctly, you propose to create a "catch-all-future-updates" version, where the user can `app deploy --force` and it will pull the latest minor/patch version of the previous major version. Sounds like a good hack! Thanks for the explanation.
ineiti marked this conversation as resolved
ineiti commented 2026-06-14 07:59:27 +00:00
Author
Contributor
Copy Link
Copy Source

@dannygroenewegen updated the MAINTENANCE.md file with your suggestions. Let me know if I missed anything, please.

@dannygroenewegen updated the MAINTENANCE.md file with your suggestions. Let me know if I missed anything, please.
👍 1
dannygroenewegen approved these changes 2026-06-14 18:53:13 +00:00
ineiti commented 2026-06-15 05:46:15 +00:00
Author
Contributor
Copy Link
Copy Source

So who should be in the initial maintainers list? I'm happy to be on it. Shall I add you, too, @dannygroenewegen ? @3wordchant ?

So who should be in the initial maintainers list? I'm happy to be on it. Shall I add you, too, @dannygroenewegen ? @3wordchant ?
👍 1
3wordchant commented 2026-06-15 20:59:34 +00:00
Owner
Copy Link
Copy Source

I would prefer not to, sending y'all good luck though

I would prefer not to, sending y'all good luck though
ineiti commented 2026-06-16 20:05:37 +00:00
Author
Contributor
Copy Link
Copy Source

Pinging the last couple committers to this recipe - do you want to appear as a maintainer?

@carla @decentral1se @moritz @oxaliq @simon @iexos @p4u1 @Apfelwurm @ammaratef45

Also, one of you will have to add me to the repo so I have write access :)

Pinging the last couple committers to this recipe - do you want to appear as a maintainer? @carla @decentral1se @moritz @oxaliq @simon @iexos @p4u1 @Apfelwurm @ammaratef45 Also, one of you will have to add me to the repo so I have write access :)
ammaratef45 commented 2026-06-16 20:17:15 +00:00
Owner
Copy Link
Copy Source

I would prefer not to, sending y'all good luck though

I +1 this, wish I had capacity

> I would prefer not to, sending y'all good luck though I +1 this, wish I had capacity
carla commented 2026-06-17 07:15:24 +00:00
Owner
Copy Link
Copy Source

@moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :)

@moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :)
ineiti commented 2026-06-17 20:40:32 +00:00
Author
Contributor
Copy Link
Copy Source

@moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :)

I'm actually realising that my way of working might not be possible here: toolshed/organising#678 - if I'm not allowed to use LLMs when working on the recipes or tools, I won't have the necessary time to participate in this wonderful project :( Which of course I understand and will respect. But then I'd have to remove myself from the README.md, and I'll add you :)

> @moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :) I'm actually realising that my way of working might not be possible here: https://git.coopcloud.tech/toolshed/organising/issues/678 - if I'm not allowed to use LLMs when working on the recipes or tools, I won't have the necessary time to participate in this wonderful project :( Which of course I understand and will respect. But then I'd have to remove myself from the README.md, and I'll add you :)
ineiti added 3 commits 2026-07-03 13:07:34 +00:00
Proposing a MAINTENANCE file 347b3197bc 
Cobbled together a file with the help of Claude.
I did re-read all of it, manually edited some parts,
and asked for modifications.
Adding suggestions from @dannygroenewegen 275c1154da
Adding maintainers to README.md
continuous-integration/drone/pr Build is failing
Details
3eab656a84
ineiti force-pushed maintenance.md from bc7a2aa62b to 3eab656a84 2026-07-03 13:07:34 +00:00 Compare
ineiti commented 2026-07-03 13:18:21 +00:00
Author
Contributor
Copy Link
Copy Source

OK, looks like currently only @dannygroenewegen and me want to maintain this recipe. Also, the decision for/against/how wrt LLMs seems to take some time. In the meantime I link to the draft of the AI Policy I cobbled together (w/o an LLM...) in the MAINTENANCE.md.

So if @moritz @simon @carla agree with this last change, I only need to convince somebody to give me actual access to the /coop-cloud organisation... @decentral1se is that you?

Once somebody signs me up, I'm OK with merging this PR, and I'll be happy to help move nextcloud to version 34...

OK, looks like currently only @dannygroenewegen and me want to maintain this recipe. Also, the decision for/against/how wrt LLMs seems to take some time. In the meantime I link to the draft of the [AI Policy](https://git.coopcloud.tech/c4dt/ai-policy) I cobbled together (w/o an LLM...) in the MAINTENANCE.md. So if @moritz @simon @carla agree with this last change, I only need to convince somebody to give me actual access to the /coop-cloud organisation... @decentral1se is that you? Once somebody signs me up, I'm OK with merging this PR, and I'll be happy to help move nextcloud to version 34...
carla commented 2026-07-06 12:00:48 +00:00
Owner
Copy Link
Copy Source

Hey !
Sorry for the late response, yes as you see we also have few capacities in these days. So thank you for taking care of the recipe :)

Hey ! Sorry for the late response, yes as you see we also have few capacities in these days. So thank you for taking care of the recipe :)
👍 1
Some checks are pending
continuous-integration/drone/pr Build is failing
Details
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u https://git.coopcloud.tech/ineiti/nextcloud maintenance.md:ineiti-maintenance.md
git checkout ineiti-maintenance.md
Sign in to join this conversation.
Reviewers
No Reviewers
decentral1se
dannygroenewegen
Labels
Clear labels
bug
Something is not working
 documentation
For issues that are calling out documentation gap
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
3wordchant aadil (Aadil Ayub) abra-bot (Abra Bot) ammaratef45 amras (Sarma) Apfelwurm appletalk arjan basebuilder BornDeleuze Brooke carla cas (Cassowary) codegod100 coopcloud cyrnel decentral1se (decentral1se) dede devydave fauno (fauno) flancian Frando iexos jade (Jade Ambrose) javielico (Javielico) jjsfunhouse jmakdah2 joe-irving (Joe Irving) kawaiipunk (KawaiiPunk) knoflook kolaente lambdabundesverband linnealovespie marlon (marlon) mayel mirsal moosemower moritz nicksellen notplants oxaliq (sorrel) p4u1 pau pharaohgraphy (Andrew 🐦‍🔥❤️‍🔥✴️) PhiNatalie renovate-bot (Comrade Renovate Bot) ripclap rix rscmbbng sef (sef) simon sixsmith (Sixsmith) stevensting tobias trav val (val (he/him)) vaznasty virtualboys wolcen (Chris Thompson) wykwit xynosis yksflip
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#81
Delete Branch "ineiti/nextcloud:maintenance.md"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?