Timeline for an 18.x release?

Oh come on. What did you expect from a release date? A date in the past? June should be fine.

"Make regular, predictable release cycles coupled with community provided device testing feedback." - Second goal of "LEDE" when it announced.
LEDE 17.04 had the release plan and it's followed. But from my view, OpenWrt 18.x is not so predictable.

I don't care which exact date it release, just think a predictable plan is necessary.

1 Like

I prefer a plan that produces polished releases rather than one that produces predictable releases.

That's an ok thing to prefer, but then you have to expect people asking the question all the time :wink:

Openwrt 18.06 has been branched today.

Assuming a similar timeline as indicated above (from mailing list), the final 18.06 might happen in mid-June.

4 Likes

Excellent news, thanks for sharing.

I don't mean to be argumentative (especially with someone who has done so much good for the project), but...

I have come to the conclusion that the only way to get a release (of any quality) is to set a fixed date for each release. Otherwise, none of the benefits of the newest snapshot version will ever get into the hands of people who want to run a stable release.

Because the dev's are working hammer and tongs on a variety of unrelated features (check the messages at https://lists.infradead.org/mailman/listinfo/lede-dev), there will never be a "natural break" in development that allows for a release.

Instead, we should pick a release frequency (two, three, or maybe four times a year). At the appointed time, we declare (with sufficient warning) the next Release Candidate. If a feature is ready, then it goes into the release, otherwise, it "catches the next bus" (which is only 3, 4, or six months away).

Ubuntu does this with their X.04 and X.10 releases, and it clearly works well. I think it would work well for OpenWrt as well.

7 Likes

Why not? We are in a discussion forum!

I share your point of view, completely: yes, it is good to have deadlines, or we will have and endless beta version that never becomes stable. But deadlines should be more "final date to include new features" than "final date to release". Once you declare a release candidate, the final version should only be published when it is done. I think we agree.

We agree. Thanks.

Agreed. Branching should be done on a predefined date. Release should be when said branch is deemed release worthy.

Some historical perspective:

Old Openwrt infra had a really cumbersome release generation system, which contributed to slowing the release frequency, a release every 18 months or so in 2010-2015. And there were several months between RC versions.

That was one major reason for LEDE fork split-off, and the LEDE buildbot / release mechanism was redesigned to be more lightweight. LEDE 17.01 was released in Feb 2017, and there was a 17.06 on the roadmap with dates. The published goal was 2 releases per year, I think.

LEDE was pretty much on track with that, but then the Openwrt/LEDE merger talks started again and the merger got accepted in May 2017, which prevented new LEDE branded major releases. But the merger only finally happened in early 2018, leaving things in limbo for quite a long time.

Early 2018 saw some new features, like more targets with 4.14 and flow offloading. Then the planned 18.0X got delayed at the last minute due to the DNS outage (of the old Openwrt domain infra) and then it took a while to get the buildbot into green status again, as some minor changes broke some targets during the outage.

Regarding the previous discussion viewpoints, I pretty much agree with the main tune of the discussion. Frequent releases are good, but they need to also have good quality. I feel that the release target dates are both for a deadline for including new features, and for branching the release branch as soon as all looks good in buildbot (as it makes no sense to branch when compilation is broken). Then after the branching 2-3 RCs get compiled and the branch has a few weeks time to mature before the final release.

All developer activity tends to stay on master, so getting the final release off rather quickly after branching is a key priority. Otherwise the RCs just float around, although no real development happens any more in the branch.

Having also followed the Firefox development for years (with 6 week release frequency), the rapid release train keeps things moving and brings new features to the end users quickly. The endless beta of buildbot snapshots is ok for enthusiasts. but not for the general user populace.

For Openwrt the goal of 2-3 major releases per year is more realistic, taking the complexity (devices, kernel, feed packages) into account.

Hopefully after 18.06 we are again on the path for more frequent major releases.

4 Likes

2-3 releases (Ubuntu Linux style) per year would be so amazing for OpenWrt. The released structure was so much improved with LEDE, as short lived as it was, hoping that translates back to OpenWrt for 2018.

I hoped they would make a concise support list, 2-3 releases per year, and focus on quality/performance. Say like: Netgear 1900ACS/3200ACM/32X. Linksys R7800/R9000. TP-Link Archer C7/C9, etc. And just drop everything outside the main routers. Nothing is worse than trying to support 100 things poorly.

Well, as the merge was mostly about renaming LEDE to Openwrt and keeping all LEDE infra intact (except the wiki layout etc.), the LEDE release system is still there and in use. So, the technical mechanisms are there.

Just now the 18.06 phase1 buildbot is already crunching 18.06 snapshot images and SDKs, and packages will get built in phase2 once SDKs (from phase1) are available. It will possible to use opkg to install 18.06 snapshot packages into 18.06 builds in 1-2 days.

Agreed to a point, but I'd propose a two-tier approach, have a set of devices that are committed to and where high quality standards are met, and then have additional targets that might be supported, but where certain issues will not stop the final release. That way the committed device set is guaranteed to see frequent, reliable releases, and the others might need to skip a release if a certain feature/function is less than perfect. But for those unaffected, they still get an official release.

Just to add my 2 cents, considering this project churns out generally usable snapshots, but with a moving target for the kernel, it is extremely valuable if a release is made on a time schedule rather, as it enables all the new features to be used with the possibility of later package installation over the long-term. Without this possibility, all the users of unsupported devices would have to wait until something else warranted a new release, which may take a long time.

In other words, I think this is more than a matter of preference. I think predictable releases make sense for this project.

LP,
Jure

1 Like

Question about the buildbot. Google cloud infrastructure allows pretty cheap high powered computing on preemptible instances. Like you could get 64 cores and several hundred gigs of RAM or some such thing for 12 hours in the middle of the night, costing around 5 to 10 bucks. Would setting that up be useful? Is that already what's done?

Depending on where OpenWrt's build servers are, that's likely far more expensive at a cost of ~$1,825 - $3,650/yr.

  • While many OpenWrt users likely wouldn't have an issue donating to OpenWrt (I've wanted to for some time, but have no clue where to contribute funds), how would OpenWrt guarantee that amount would be donated year in and year out?

You only pay for the actual run time. My assumption was it runs maybe once a week or the like. $10 a week is $520 a year. Perhaps my assumptions are incorrect. How long does it currently take to build a full release candidate image for every target? How often is it built? What kind of machine is it built on?

1 Like

It is an always on buildbot , where new commits trigger new builds.
There can be several buiildslaves.

Kernel and firmware images are built separately, and that took maybe 36 hours initially. Next build round will be quicker as tools and toolchain for all targets have already been built.
http://release-builds.lede-project.org/18.06/images/grid

Packages buildbot has been crunching 48 hours and has compiled maybe 2/3 of targets.
http://release-builds.lede-project.org/18.06/packages/grid

There is similar buildbot for 17.01 (that compiled new images and packages after changes), although no formal releases are made. The goal is to ensure that breakages are noticed quickly.

And the main buildbot for master, with several buildslaves
Images https://phase1.builds.lede-project.org/grid
Packages https://phase2.builds.lede-project.org/grid

So it is not about let's hire a machine for a few hours. I have no specifics about the actual hosts. But I know that some people have contributed buildslaves.