Gluon v2021.1 Tracking Issue

[mweinelt]

A future release. This issue is for things we don't want to forget.

• mention upgrade support only for v2018.2.x and newer (to be able to remove some old migrations)
• use OpenWrt 19.07.7
• bump routing/packages
• docs: Add v2021.1 release notes #2230
• https://github.com/freifunk-gluon/gluon/wiki/Release-Process

[rotanid]

as discussed a while ago on IRC, we want to release this a short while after the upcoming OpenWrt branch is created, which will happen soon^TM

currently, we have have 4 open Pull Request in this milestone by @NeoRaider @blocktrron and @2tata - do you intend to finish these for the release or should we postpone them to v2021.2 ?

[mweinelt]

Our next branch is using openwrt-21.02 branches since yesterday. I'd say we should merge into master soon and begin proper testing.

[rotanid]

erm, no? we discussed we want to release on 19.07 and immediately switch master to 21.02 afterwards...

[blocktrron]

@rotanid Actually, that was his plan when we talked about this today. I assume he just missed this step.

[rotanid]

ok, and as 19.07.7 has just been tagged, that's a nice opportunity

should we include routing bump, too?

EDIT: done

[AiyionPrime]

Is WireGuard support something wanted in this release or a later one?

[mweinelt]

Big features usually only in new major releases.

[AiyionPrime]

@mweinelt Like from 2020.2.2 to 2021.1?

[blocktrron]

Currently we are in a position where we could simply backport everything and do another minor release, as our feature delta isn't that big.

In the past, our / my rough roadmap was to do a v2021.1 based on OpenWrt 19.07 and do a v2021.2 with feature parity based on OpenWrt 21.02, as migrating all ar71xx boards will take a longer period of time. However, this would result in additional maintenance effort, as maintaining two releases with targeted feature parity isn't really efficient with resources, especially given the delta between 19.07 and 21.02. And i don't see us doing that, given we've maintained two release tracks at max in the past.

From my perspective, there's a big interest in WireGaurd support clashing with a protective attitude not trying to break stuff (the same we see in the ath79 migration RFC from months ago). My thought currently would be to skip the v2021.1 release in the projected form, move master to the 21.02 branch asap, nuking ar71xx in the process and adding wireguard support.

With that path, we could merge in Wireguard support quite quickly, motivate users to verify ar71xx --> ath79 / ramips update paths and possibly add support for custom switch configurations on these DSA platforms. This will break stuff on the way, but i expect we can learn a lot for the upcoming migrations for that.

v2020.2 could be a LTS until OpenWrt 19.07 maintenance is stopped, providing security patches for communities not interested in this step / waiting out for the dust to settle (which is a fair assumption, given the amount of communities who were / are still on v2016.2 / v2018.2).

Maybe my plan is dumb from front to back, in which case please provide alternative suggestions.

[rotanid]

@blocktrron i don't like this, especially your "third option", i find both other options better (doing everything as a backport and continuing as planned 2-3 weeks ago) than postponing releasing what we have even further and putting it in some big feature block release....

[mweinelt]

I'd say we cut the current milestone short and get this release out before 2021/06 as is. Maybe with #1357, if @T-X rebases that in time.

[rotanid]

fine with me