coop-cloud/nextcloud
9
5
Fork 11
Code Issues 18 Pull Requests 9 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 10 Commits 3 Files Changed 2 +97
ineiti commented 2026-05-22 10:24:44 +00:00
Contributor
Copy Link

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 added 1 commit 2026-05-22 10:24:45 +00:00
Proposing a MAINTENANCE file
Some checks failed
continuous-integration/drone/pr Build is failing
Details
3d7dfed415 
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

@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
@ -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

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

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

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
@ -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

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

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

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

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

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 added 1 commit 2026-06-14 07:58:40 +00:00
Adding suggestions from @dannygroenewegen
Some checks failed
continuous-integration/drone/pr Build is failing
Details
519453c398
ineiti commented 2026-06-14 07:59:27 +00:00
Author
Contributor
Copy Link

@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

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

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

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

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
ineiti added 1 commit 2026-06-16 20:23:17 +00:00
Adding maintainers to README.md
Some checks failed
continuous-integration/drone/pr Build is failing
Details
bc7a2aa62b
carla commented 2026-06-17 07:15:24 +00:00
Owner
Copy Link

@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

@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 :)
Some checks failed
continuous-integration/drone/pr Build is failing
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
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 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 abra-bot ammaratef45 amras Apfelwurm appletalk arjan basebuilder BornDeleuze Brooke carla cas codegod100 coopcloud cyrnel decentral1se dede devydave fauno flancian Frando iexos jade javielico jjsfunhouse jmakdah2 joe-irving kawaiipunk knoflook kolaente lambdabundesverband linnealovespie marlon mayel mirsal moosemower moritz nicksellen notplants oxaliq p4u1 pau pharaohgraphy PhiNatalie renovate-bot ripclap rix rscmbbng sef simon sixsmith stevensting tobias trav val vaznasty virtualboys wolcen wykwit xynosis yksflip
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#81
No description provided.
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?