Nothing new that I’ve heard about either if or when. If I were using release builds, I’d plan on 19.nn
keep looking here https://openwrt.org/releases/18.06/start#roadmap
tho 17.01.7 never made it out https://openwrt.org/releases/17.01/start#roadmap
hopefully 19.nn will be added at some point as well https://openwrt.org/releases/start
Anyone hear anything new about an OpenWrt 2019 release? It's been almost a year since 18.06.
The resources for finding out about upcoming releases have not changed since this thread began. http://lists.infradead.org/pipermail/openwrt-devel/ is perhaps the best for non-developers to check, or subscribe to the list yourself to follow on a regular basis.
1 Like
One more vote for an 18.06.3, as there are a ton of what look to be good fixes for mt76, wifi specifically.
Given that not a peep has been mentioned regarding either a .3 nor a 19.06 release in the dev mailing list in the past 30 days, it's pretty hard to make plans.
I recall that one of the goals of the LEDE/ new OpenWRT project was to have more regular and predictable releases, which it has largely met, but it seems more vague now.
If there were to be a a new drop of a 19.06, I'd expect some discussion on the list, and engagement of the community in testing a branch. But neither seem to be happening (publicly).
If you are desiring updated firmware, master and snapshots are always available.
The sysupgrade from master now can automatically create a list of self-installed packages to make re-flashing a new snapshot a lot easier.
If you really insist on sticking with a given snapshot rather than simply flashing a new one, see
Thanks Jeff, appreciate the details. I am deploying recent snapshots in my testing, which is why I'm aware of the benefits of the recent mt76 fixes, but the project I'm affiliated with has a strict policy of using only tagged releases for our distributions. This is so we can report any future issues back to the community based on clearly tagged and widely used releases.
Even as an individual end-user, my preference is to only rely on the official releases on my home network.
1 Like
I certainly understand the desires and policy of your organization.
Without those limitations, the git commit or the build reference shown LuCI of the banner is more than sufficient to allow developers to determine the code in play. At least in my experience, enhancements (meaning most anything that doesn't cause a major loss of functionality; "improve wireless" falling into "enhancements") are more than likely to happen on master, not on a release branch, even if they are backported later.
I'm noticing that the (4MBish) overlay on my WDR4300 is filled to the brim, with a fairly minimal install (luci-ssl, luci-app-upnp, sqm-script-extras, luci-app-sqm) and running opkg-upgrade from time to time.
So it would certainly be nice to have a new release that would push all the updates into the firmware again.
But I'm just a nobody on the project.
(Edit: 4MB overlay, the router itself is 8/128)
As far as I know if you create a new 18.06.2 build using the Image Creator, it wil have all updates.
3 Likes
And that would still be compatible with the public opkg repositories out of the box? Or are you then expected to build all your own packages ?
4/32 warning that has been up for a couple years now—time for a new router with at least 16/128. Good-quality devices start at ~US$20
Edit: Yes, an image-builder assembled image uses the public package repositories. With only 4 MB of flash, you should expect that every package change you desire will require a new ROM. Upgrading packages in-bulk is not recommended, ever, for a variety of reasons.
1 Like
What are you more interested in:
- 18.06.3
- 19.x
?
I have the feeling that the latter might come first and ... soonish. 
4 Likes
I'd love to know what people expect from a new version except for incremented version number just for the sake of it which much seems to be the case. Normally I'd say run master and report bugs but given that master is still on 4.14 which is pretty dated by now and many upstream projects have already moved on the master branch seems to have lost steam so to say...
@jeff
I even warned people about that several months before it became "official" which didn't sit well with some but later as seen became inevitable in order to drive the distribution forward.
3 Likes
Well, if you look closely.... 
5 Likes
This is the heart of the matter.
git log --pretty=oneline v18.06.2..openwrt/18.06 doesn't show much there other than kernel-version bumps.
If you want significantly new or improved functionality, you should look to snapshots or v19.
remotes/openwrt/openwrt-19.07 (No, that's not a release, but just the first step of many)
NOTE: If you've got a 4/32 device, now is the time to start budgeting for an upgrade.
1 Like
Honestly, the only thing I'd like to see that isn't in the 18.06 branch (but is in master) is an updated version of kmod-sched-cake. Mainly to see how the fairness changes to the dual modes work with some edge cases I have at home.
1 Like
Let's be fair: that popped up after we both posted 
Some of those bumps contain security fixes, the same goes for e.g. OpenSSL, cURL, mbedTLS, ...
There was talk of a .3 right after the latest WPA2 vulnerabilities were published.
1 Like
there's no luci-app-sqm in the most recent openwrt-18.06 checkout from github. But at least the sqm scripts are there.
Also the kmod (kernel module) opkg packages from the 18.06-SNAPSHOT repositories are very incompatible with self built kernels (maybe because the module is already built-in). I guess I'll have to attempt the recovery procedure for the very first time.
Anyways, thanks for starting the process of releasing OpenWRT 19.07