Lynx, with the ease of installing the latest snapshot version in stable branch + opkg(s) via AUC, is there any sense in installing a point in time release (or release candidate)?
Why install RC1 over a 22.03-SNAPSHOT?
Edit: I think this may be outside the scope of the initial post, but I was curious what other's use cases are.
Good point. And this may be just me being an ignorant OpenWrt newbie, but am I not correct in thinking that an rcX is more stable than a stable branch snapshot? @hnyman could you please comment on that?
I have been using master snapshots because for RT3200 nothing else was available. But I actually use x3 of these for business use and stability is particularly desirable for me (albeit admittedly things have been extremely stable so far on even the master snapshots, so all of this may be theoretical, but I am still interested anyway).
The pretty much only major reason is if you want to later install kmods from the download repo without re-flashing the main firmware. The snapshot goes forward and kmod compatibility weakens as time goes on, but stays intact in the static release.
Other imaginable reason is that you might want to "use the official release build". Release builds are made from the same branch as the snapshots, and there is no major special testing befire tagging, so the reason is rather weak in reality. Sure, possible major bugs in a release are probably fixed more quickly than bugs at any random moment.
Otherwise the release branch head, the 22.03-SNAPSHOT on auc terms, contains fixes made after the release and is likely better than the release. E.g. right now, the 22.03 already contains firewall4 fixes and mt7622 uboot pstore fixes that have been backported from master after the rc1 tagging.
Personally I always make my own builds from the branch HEADs.
Ah, so it sounds like I have been mistaken in supposing rcX is in theory more stable than branch head snapshots? If so, I'll revert to the latter.
Usually there is not much difference. Rarely the backports contain bugs that are discover later, but that may also happen before a release. (Like said, major bugs in a release may get more rapid attention than the same bug at a random moment.)
But there is nothing major/special in the release tags regarding stability.
Of course, if you are running a production environment, you likely would not upgrade all routers to the random build at the same time, but would see if the build causes any problems in one of them. But the same applies also for releases...
It pays to look at the core OpenWrt source changes. E.g. right now there just a few mt7622 fixes (touching also RT3200), firewall4 fixes (firewall4, ucode) plus iwinfo changes. Nothing major to either direction. Likely no major risks, but quite possibly fixes for the rather new firewall4.
Thanks a lot for your helpful explanations. I struggle to understand the above.
Do you mean that when there is a release candidate, and that release candidate is found to have bugs, there tends to be a more rapid resolving of those bugs than otherwise? If so, I presume that would point towards using the branch head in which such bugs have been resolved?
Not really the release candidates, but the later actual releases, 22.03.0, 22.03.1 etc.
If major bugs would be found in a release, a new point release would be made more quickly.
The branch head likely contains more fixes than the old fixed release did, but on the other hand it may also contain new bugs. That is the drawback.
But release candidates, like the current rc1, are still just test builds in any case.
OK thanks, but is it fair to say at least that branch head is more stable than master head? So maybe a good compromise?
Sure, a release branch is expected to be more stable than the bleeding edge development master branch.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.