Is this still official policy? I just did exactly that, simply navigated to https://downloads.openwrt.org and the new release (24.10.2) is right there--under "stable release."
Maybe create a new category in between "Stable Release" and "Old Stable Release" called something like "Upcoming Release" or "Early Testers' Release" and when the release team is certain that the new stable is ready, simply mv Stable to Old Stable and mv Upcoming (or whatever) to Stable Release.
I would hope that your tools are parameterized enough that this change in process would not cause earth-shattering disaster.
It does look like the directory has been updated. This would be a question for the dev team, really. But broadly speaking, the issue is simply that the build bots may not be done and issues may arise. Waiting until the official announcement ensures that you will have a smooth upgrade.
What I actually meant was that there needs to be a separate listing on that page for a release that has not been announced yet. Some people need to test the new release before it is announced. The trouble is that someone who is maybe trying out openwrt for the first time might mistakenly download the Stable Release without realizing it is not ready for production use just yet.
I have a script that goes out once in a while and checks that page for indications of a new release. Unfortunately, the way the protocol now works misleads it into believing a new release is out. This is still helpful to me, though, because I can begin using the new releasein testing and to see what has changed.
How does one "check for the announcement?" I don't want to do this manually.
I thought my suggestion was constructive.
BTW, according to psherman's OP from 3 years ago, it sounded to me like the Stable Release link might still be getting updated before the official announcement. That's why I made the suggestion.
The automation that provides the ASU server (and hence all of the ASU clients) with version information was improved recently, as it had been a manual process and often lagged releases badly. The automation looks at the release branches in https://git.openwrt.org/?p=openwrt/openwrt.git;a=tags and immediately pushes the result to https://downloads.openwrt.org/.versions.json This was implemented over the course of 24.10, and has no throttling, so it precedes the official announcement of the release.
It's just something we may have a look at to better coordinate with the announcements rather than the git state.
Actually it was sort of the opposite. People would watch the git repo and see a new tag, then start trying to install before it was released or even fully built (usually takes a few days for the image builds and all the package builds). ASU lagged behind and they'd ask why Firmware Selector et al wasn't showing the "new release" before the announcement.
There are a lot of moving parts when a new maintenance release or new branch is introduced, so it's a big job and a lot of it is manual (thanks, @hauke!). The bottom line is that OpenWrt doesn't have the resources of Red Hat or Ubuntu, so it is what it is; it's surprisingly great, considering it's just a bunch of volunteers chipping away at it in our spare time.
Old Stable is 23.05
Stable is 24.10
Early Testers is Snapshot
Current Stable is described in detail here:
Both Stable and Old Stable are listed here:
End of life is also listed above.
I'm not sure what else you want a volunteer run project to do?
Openwrt is very transparent in what is included in each release, if you have wandered in to the downloads server I would hope someone would read up on the changes before trying to flash anything.
24.10.2 is not confirmed yet and could be pulled if there is a breaking bugs for any architecture.
All I did was make a suggestion: Use the "mv" command a couple times (as I described, generally) as the last step in making the newly-built area available to the user world. I'm not sure how that small change to the release process is a huge imposition on limited resources. If anything, I'd think it uses a lot less resources than wholesale copying.
I never accused this project (or any other, for that matter) of being anything less than transparent, so I am not sure where the attitude is coming from, people. Again, it was just a (very) friendly and (hopefully?) constructive suggestion to smooth out the release process. I've worked on projects as a configuration manager and that's exactly how we did it. One project had a release matrix of at least 4 dimensions (application vendor vs vendor release vs unix variant vs our product lines). Not nearly as complex as openwrt, certainly, but there was only one (1) person performing this role. It worked, and that is all I am saying about it.
