Timeline for an 18.x release?

For Developers
7

Thanks for the find and the share Rich, let's hope that happens.

8

I'm on LEDE snapshot so numbers are less important for me, but serious usb hdd corruption bug (on Rampis 4.14/4.9) is. So IMHO it should be fixed first.

9

I have not kept up on the developer messages to know what they're considering. Here's the archive...

https://lists.openwrt.org/pipermail/openwrt-devel/2018-March/thread.html

1 Like
10

https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-March/001751.html says people are taking about by the first week of April

11

I am a developer (although not Lede/OpenWRT) and I understand the frustration associated with the question.

That said, it can be mitigated to a large extent by having and maintaining a roadmap timeline, and making it easy to access (e.g., one click off the main page). I know that the LEDE project tried to do something like this. I would encourage the team that this is a good practice. It enables the Devs to do what they really want to do without answering this question regularly.

Just my 2 cents - take it for what it’s worth.

1 Like
12

Hauke Mehrtens wrote about the preliminary timeline (subject to delay in case of critical bugs): https://lists.openwrt.org/pipermail/openwrt-devel/2018-April/043747.html

  1. Branch of openwrt-18.05 at 7. April
  2. Create openwrt-18.05-rc1 release on 14. April
  3. Create openwrt-18.05-rc2 release on 28. April
  4. Create openwrt-18.05 final release on 12. May
1 Like
13

Any update on this?

14

Yes. Keep an eye on the LEDE mailing list for now; it's unclear when/if the original OpenWrt mailing list will become available again.

15

I really wish openwrt/lede have some firm release plan. It looks like few devs cares about it in the mailing list. proposed date is always next month or next week but never come. This makes me think if the project and community are still healthy

16

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

17

"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.

18

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

1 Like
19

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

20

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

21

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
22

Excellent news, thanks for sharing.

23

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
24

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.

25

We agree. Thanks.

26

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