Create a maintaince release schedule to keep containers up to date

Some of the package we are maintaining have binary releases like container images. We need to create a scheduled maintenance cycle to update them once in a while to keep the dependencies up to date. To do so, we will need to determine a workflow for us to periodically review the repo covered for the need for maintenance release.

Here is the plan:

we first identify and document the repos that are covered by this maintenance release policy.
then every 3 month, we check each of these repo to determine if we wants to create a maintenance release.
we wants to create a maintenance release if there are no other releases in the past 3 months.
each maintenance release is an new tag of a minor version bump with no changes other than update dependencies.

There are a few ways to automated this, like creating issues automatically (as suggested bt @cohosh ) or just set a due date on a ticket to make it due every 3 month(and then adjust its due to extend it <- which might require less initial setup).

Related Meeting Notes

https://meetbot.debian.net/tor-meeting/2026/tor-meeting.2026-03-19-16.01.html

16:07:15 <cohosh> next topic is: Release schedule planning for containers
16:07:32 <Shelikhoo[mds]> yes, we can wait maybe a week and start getting the update to the tor browser
16:07:49 <Shelikhoo[mds]> that is all the updates on that topic from me
16:08:19 <Shelikhoo[mds]> yes, some users are reporting that they see webtunnel container didn't get an update for too long
16:08:37 <Shelikhoo[mds]> I have started to tag a new version and release a new container image
16:09:12 <Shelikhoo[mds]> it might make sense to have a policy to release a new version once in a while even if there is no update from the code itself
16:09:33 <Shelikhoo[mds]> as the container image need an update to catch up with dependencies update
16:11:21 <Shelikhoo[mds]> do we wants to set a schedule like once every 3 month, to update new versions
16:11:55 <cohosh> 3 months seems doable
16:11:58 <Shelikhoo[mds]> (waiting for response...)
16:12:16 <cohosh> the snowflake container update is automatic as part of pushing to main right?
16:12:47 <cohosh> i was just looking at the webtunnel commit history to see if this makes sense for us to do as part of CI
16:12:55 <Shelikhoo[mds]> when we push to main, the "unstable" version get updated
16:13:24 <Shelikhoo[mds]> but the stable/latest version do require a manual release
16:13:30 <Shelikhoo[mds]> with a new version number
16:13:39 <cohosh> ah i see
16:15:08 <cohosh> if it has to be manual, is there a way to schedule the creation of gitlab issues at least?
16:15:25 <Shelikhoo[mds]> we can maybe have a list of project we wants to add to this "regular maintenance update list", and every 3 month, we check each of them to see if we wants to create a maintenance release
16:16:12 <cohosh> i'm willing to try it
16:16:53 <Shelikhoo[mds]> yeah, I think I can write an issue to track this
16:17:28 <Shelikhoo[mds]> but the target would be creating a maintenance release every 3 month, if there is no other release in between
16:17:43 <cohosh> we should in general be more willing to tag new versions, but the webtunnel code is shockingly stable
16:18:32 <Shelikhoo[mds]> our improvement is mostly client side inside lyrebird
16:19:04 <Shelikhoo[mds]> as for server side improvement, there is no funded grant to do that yet
16:19:45 <Shelikhoo[mds]> there are things like h2 or h3 support we wants to create
16:20:08 <Shelikhoo[mds]> but it was not funded yet
16:20:16 <Shelikhoo[mds]> eof from me on this topic
16:20:23 <cohosh> ok thanks Shelikhoo[mds]
16:20:32 <cohosh> anything else for today?