Don't suggest master to people looking for stable releases @diizzy. We've been over this before.
@Per I have been happily running my own builds off the 18.06 tree. I've been testing mt76 with a master build though for the past few days (issues popped up with recent updates which the dev has since rolled back on the 18.06 tree).
I'm honestly getting really getting tired of your claims which you have to prove in some way.
Please do tell how you came up with that conclusion and show facts to back it up rather.
There's no extensive testing of "stable"-branch, probably even less than master in that regard.
I can happily share data from a bunch of devices (MT7621 specifically) which will prove you the opposite. That said, you can get a bad/unstable build but that goes both ways.
If you are building by yourself, then just build from 18.06 branch HEAD.
The 18.06 branch only gets fixes and security patches, so the branch stays stable all the time.
If 18.06.2 gets released at some point, it will just be from the head commit in 18.06 at that time, a semi-arbitrary commit. There is no special "let's get this done before 18.06.2" as all interesting development happens in master in any case.
That kind of insinuating, baseless statement does not even deserve a response. You've been asked more than once to drop the crusades you're waging on multiple fronts. Keep this a nice place for everyone. Try seeing things in perspective, and understand what someone is asking, and actually formulate a response that helps them, instead of just foisting your point of view on them. Quit wasting other people's time.
Hi I am new to Linux embedded Linux and Git. Could somebody be so kind to explain difference between git branches and tags and how openwrt project uses them. I was assuming that both tag 18.06.0 and 18.06.1 were stable releases ? Or not ?
I am not going into git details as net is full of git tutorials. But briefly, branch is a chain of commits, and tag points into an individual commit in the chain.
18.06 is a branch spinned off master in June 2018, and 18.06.0 and 18.06.1 have been released from it. There are already more fixes in 18.06, so 18.06.2 will have those.
But still, 18.06 is mostly June 2018 code, while current master has already five months of new development since then. And new 19.01 will be branched off master in a few weeks as a new release branch.
Openwrt branch and release strategy is illustrated in the discussion here. Hopefully it clarifies things.
Hi hnyma,
thanks for pointing me to that
so 18.06.1 is release with fixies on the already stable release 18.06 ?
There is no "stable release 18.06". There is the branch 18.06, and the 18.06.0 and 18.06.1 releases are historical commits in that branch.
New try:
Ps.
Like linked above by anomeome, there will likely be a new 19.01 branch soon (in December-January). It will naturally be branched off from the then current HEAD of master, so it will contain lots of new stuff compared to 18.06, quite similarly as 18.06 is ahead of 17.01.
Hi thanks.
I wish I could give you more than one thumb up !!
Thanks again its more clear to me now
Sorry to add to the "noob"ishness of this thread.
Thank you in advance.
It depends on your needs. Releases are easy and good enough for most people. But if there is e.g. a fix that your device needs, an own build is needed. And making an own build enables you to integrate all packages that you want.
Depends on your adventurousness. Master is usually ok, but sometimes new stuff causes problems. 18.06 should be ok always.
You would use the full toolchain for an 18.06 build. Download directories have only 18.06.1 release imagebuilder and master snapshot imagebuilder.
If you don't have anything constructive please don't reply, it'll be much more productive for everyone. As @hnyman mentioned only "minor" fixes and security commits goes into the stable branch and support for MT7621 overall is much better in master (major changes) however if you think that claim is incorrect feel free to point to commits where noticeably changes are made for that SoC in the stable branch. You at least a few popular community builds following master including at least one for MT7621 (DIR-860L but still).
@Per
master is your best bet although looking at the rather scattered information about the Xiaomi 3G router however it doesn't seem to be completely stable although much better than current release binaries.
@Pocket_Sevens
Irregardless of branch/source you should always be prepared in case you get a bad flash, firmware etc. In general there's not much to gain on single core devices if they're just acting as a routers/gateways unless you want to customize packages or repack with higher optimization (may vary depending on usage).
Well, to be honest 18.06.2 would be a good idea before the end of the year as many people don't like to work with Snapshot versions. There have been significant improvements/fixes and would be a good thing to have it before preparing things to to 19.01 or whatever month it may happen.
It is a problem of bad management of OpenWRT project.
We all know many things can be improved, there are no people resources for faster development as people have private lifes etc..
But the another problem is no public, real plan for new and current (patch) releases.
In better organised projects there are roadmaps, plans about fixing issues, task priority lists. People just know better what to expect.
Here we have never ending promises of releasing new maintenance versions, and primary plan never was correctly executed.
It is obvious that most of the problems can not be resolved fastly, but is this a reason to stop releases? Maybe in case of big ball of mud like Windows 10; but OpenWRT remains a really stable OS.
Some commits are just refreshing patches, fixes. I am able to build everything myself and do not care; but please also allow many other users to use new features and get fixes faster.
I'm quite surprised how people are deadset on something called release just for the sake of it (it seems), if you want to run something more "fresh" you have snapshots which usually works fine.. As I've said before, looking at backports very few contributors "cares" about releases anyway (backporting) so it probably boils down to interest in general.
Think about issues. Is not it easier to track bugs in a known version, than if everybody has different versions of maybe both official (and non-official) build?
You should not backport new features, only fixes. That makes sense. And that requires often releases, but I've already written about it.
Watch how much space is wasted by these tens of versions - one example: https://downloads.openwrt.org/snapshots/targets/mpc85xx/generic/kmods/
The thing is, most people do not want to download Gigas of data, to then configure and compile the code (let alone many people have no clue of what compilation is).
Maybe it could be possible to generate further "stable" builds - after an initial xx.yy version is released - every 3 months, automatically from the last snapshot in that main version? E.g. 18.06.2 now, then 19.01 manually in Jan, then automatically 19.01.1 in Apr, 19.01.2 in Jul etc...
Openwrt/Lede is an amazing work, from which we all benefit. Thank you again.
It's a nightmare to do. Other distros have security teams. OpenWrt does not.
To say nobody cares about releases is incorrect. There was a recent mailing list email where it was requested that LEDE 17.01 get further support.
I personally think the snapshot model works better for OpenWrt as it is right now, bleeding edge is rarely imported apart from WireGuard more or less so it should be "safe" in most cases. To my knowledge there's no release testing procedure apart from branching it off and label a few versions BETA/RC (no constistent regression testing etc). Of course devs have a some devices on their own which are run-tested but I as far as I know there's nothining more than that. I could be wrong but I've never seen any documentation about the release procedure other than BETA/RC.
Perhaps something like quarterly snapshots (releases) with minimal backporting effort (security and major fixes)? That's pretty much what buildroot does as far as I know. In fact, I think they stick with monthly snapshots/releases.
