Release goals for 22.XX

Rich Brown richb.hanover at
Wed Oct 6 09:47:24 PDT 2021

Paul, Rafał, 

I think our emails passed in the ether... (

As I said in that message, I am very aware of the time constraints of the volunteers for OpenWrt. And I don't mean to suck the conversation into "grand strategies" without any endpoint. 

Let's focus on our next step. In my earlier note, I asked:

1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? ( 

- How do we see the time between now and March playing out?
- Are there things we should leave out? Or should the release date be shifted?

I would invite everyone to weigh in. Thanks.


cc: OpenWrt-adm

> On Oct 6, 2021, at 10:14 AM, Paul D <newtwen at> wrote:
> Wise words from the experienced!
> If making a yearly release is unattainable, isn't making point releases more achievable? Even if it's adding a single commit, point releases send a signal to the outside world that the project is still active, and e.g. that security is in focus. Any point release can be done for trivial amendments and GUI fixes. ( I do not make light of the steps involved in doing a release ). The idea being that at least these point releases can be done regularly.
> So the 'yearly' release is unattainable: is this largely due to the amount of new material that goes into the 'main/master/head' branch that needs to be picked and normalized and made stable (if that's how I might summarize making all the platforms behave consistently)? I would be fine without regular yearly releases. nightlies are available etc.
> On 2021-10-06 07:58, Rafał Miłecki wrote:
>> On 30.09.2021 03:34, Rich Brown wrote:
>>> My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in.... September. And so on - every six months (or whatever interval we believe we can sustain for the long term.)
>> This is absolutely undoable. We have too little manpower and too little
>> people actually interested in preparing releases. It takes testing,
>> checking feedback, reviewing bug reports, debugging issues, backporting
>> changes. That is a lot of work.
>> Every time we have a discussion about releases there comes an idea of
>> time-based releases. Also a lot of people have opinions on when to
>> branch and how to proceed with development.
>> When it comes to actually working on a release there are very people
>> that stay involved.
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at

More information about the openwrt-devel mailing list