When comes the next stable release 19.x

Quoted from the man himself. Mainly it just sounded cool to run kernel 5.0. Given that the next LTS is kernel 4.19, it would be the obvious choice. There probably isn't much benefit for OpenWrt right now anyway.

I've tested the change (somewhat) and I can't see anything majorly wrong with it. Anything I can do to help the pull request?

Well, @hauke who authored that WPA3 related LuCI PR has commits rights, so I guess that he will merge the code in at some point.

Are you saying that you successfully connected 2 OpenWrt devices using WAP3 - configured via LuCI?

In that case it's fortunate a year doesn't have a 0th month. So OpenWrt can never have a .0 version.

3 Likes

seems like might be soon https://git.openwrt.org/?p=openwrt/openwrt.git;a=heads 19.07 incomming

Do they have schedule to release 19.07?

Any news on release date?

Latest discussion on the mailing list:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg48100.html

"gradually getting stale" is something of a polite understatement

$ git log --pretty=oneline openwrt/master ^openwrt/openwrt-19.07 | wc -l
741
$ git log --pretty=oneline $(git merge-base openwrt/master openwrt/openwrt-19.07)..openwrt/openwrt-19.07 | wc -l
163
2 Likes

19.07 branch is already a release quality. Openwrt developers always struggled to release anything. It was declared to do a release each 6 months, but they can't do one in a year. Nobody of the core developers are interested in releasing anything. They just move master ahead.
I am quite happy with making 19.07 builds.

3 Likes

I don't think this one has been fixed yet: Flow_offloading=1 is broken on latest snapshot (4.19 issue)

Since 19.07 includes flow offloading for the first time for a number of popular devices (ath79) I think it's critical to have that fixed before releasing it.

As far as I understand default kernel version for 19.07 build version for your device is 4.14 and not 4.19

3 Likes

It is broken only on master, not on 19.07.

3 Likes

Packages that are updated at source being only committed to Master but rarely to the stale 19.x branch. By the time 19.x gets released those packages will be outdated already and who knows when the next branch after 19.x gets forked off Master - at the current pace probably not for another year.

  • Package updates are independent of releases
  • Lack of package backport/cherry pick activity is not entirely the fault of the developers, the majority of package updates happens in the feeds

Unless I am miss-comprehending various forum posts I am under the impression that packages should not be updated by the user individually/independently of release updates (sysupgrade)?


You lost me there - I would understand that would apply to packages fed from other repos (feed) than the main OpenWrt. And anything provided by the OpenWrt repo (feeds) needs to be uplifted/backported to the specific branch repo after being tested in Master repo, which does not seem to happen automatically.

There are a number of packages in Master that are on par with source but not making it into the branch. And with the current release pace who knows when Master being forked again?

Thorought the lifetime of a release, binary packages of the latest available version in the branch are automatically built and made available in the repositories. There is no release required to get the latest version of some optional package, it just needs to be backported to the branch by its respective maintainer [within certain limits].

Correct, it does not happen automatically and needs to be done by the maintainers of the respective packages. The release branch is forked once initially and used as baseline for the builds. If nobody cares about it or backports stuff into it, it will get stale.

And there starts one of the problems, that maintainers are often not interested to backport to the current branch and rather prefer waiting till Master gets forked, which can be quite some time.

But that is perhaps digressing from the thread topic.

Exactly, but in my view a release is not a simple unmaintained archived master snapshot just for the sake of getting updated packages. If this is the sole requirement for a release, one could as well use snapshots.

1 Like