Release goals for 22.XX

[Hauke Mehrtens]

On 9/30/21 3:34 AM, Rich Brown wrote:
> Hauke: My thanks also for writing up those note.
> 
> 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.)

I would decide about the name when we branch, currently I would also 
target to branch end of the year and then do the release in March. This 
all depends on how much time people have.

I would prefer to not do more then one release per year, at least I do 
not have the resources to manage that. If more people take over 
maintaining and also fixing bugs it would be nice and possible.

The problem in the past was not that we didn't had the good plan to make 
more releases, but the lack of man power.

> For each release, we need to work backwards, and make the feature freeze for the March release in, say, early January so the first RC can come out in January, we can have a few RCs leading up to a final release sometime within 60-75 days.
> 
> The reasons to do this:
> 
> - Some people can only use stable releases because of their business needs or their personality. (Or because we tell them "Only Use Stable!") Regular releases let them use the newest features.
> 
> - Contrarily, a long release cycle "traps" new stuff behind something that "isn't quite done."
> 
> - We don't waste time producing and testing patched versions of the previous release. There were seven patch releases in the 19.07 series (running from January 2020 through August 2021). A regular release schedule could have avoided many of these.
> 
> - Having a firm feature freeze date decreases stress. If a particular feature is done/substantially working, it goes in. If it's not quite ready, it can skip this release, and get into the next release. (The alternative is what I think happened with DSA. It was a big change: there were a large number of problems that took a long time to iron out. That kept pushing out the date...)

What happens if some parts are already in master and the rest is 
missing? Some targets already used DSA, but the configuration was not 
really supported in UCI and LuCI last time. With a fixed feature freeze 
we would have released without Luci support to configure some switches.

> - Customers (our users, our industry partners) gain confidence in projects that can meet their deadlines. Imre noted that "industry is using the snapshots..." but I suspect the extended schedule just worries other vendors.
> 
> Does this need a vote? Thanks.

I would not do a vote about this. The problem is not coming to a 
decision, but finding people who execute this.

Hauke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x93DD20630910B515.asc
Type: application/pgp-keys
Size: 13571 bytes
Desc: OpenPGP public key
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20211002/da4a81bb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20211002/da4a81bb/attachment-0001.sig>