In the Device and Techdata pages, we have links to the Factory and Sysupgrade firmware that people can use to get the latest stable firmware. Currently, those links contain a specific version number, e.g. https://downloads.lede-project.org/releases/17.01.4/
The arrival of each new version (17.01.5 and ultimately 18.0x.y) requires a massive and mindless edit to a huge number of pages, obscuring the useful history of recent changes, and introducing the potential for error.
It allows us to make one (and only one) more mass change to the device/techdata pages
From that point we can make a single change to redirect "stable" to 17.01.4, or 17.01.5, 18.0x.y etc.
The Downloads page would list "OpenWrt Stable" in place of the current "LEDE 17.01.4". (It would be OK to list the actual stable version in supporting text.)
All Device/Techdata pages automatically point to the new stable version.
We can post 17.01.5 rc1, rc2, etc. as needed: stable continues to point to 17.01.4 until we pull the trigger.
People who discover serious problems with the new Stable (e.g., 17.01.5) (or those who own routers that cannot support the new Stable, such as 18.0x.y, or 19.04.x) can manually edit the Techdata page to point back to the last good version. Those Techdata/Device pages will remain correct as the remainder of the wiki moves forward.
To me it actually sounds like something that @jow or somebody else might do as a symlink in http://downloads.lede-project.org/releases/ pointing to the most recent stable release directory, so that the symlink there would be updated after new stable releases. (The symlink might be "latest_stable" or "current_stable"). There would be no need to update techdata links in wiki.
We had already a "latest" redirect in the past IIRC, which leads to people reporting "I have used the latest..." instead of "I have used 17.01.4...", which will lead to the question: what latest?
Forum users reading postings 6 months after the initial "latest" will find a different "latest"....
I feel slightly better that a script makes the modifications: it minimizes the potential for clumsy errors. But I still have a number of concerns:
I have a deep concern about changing hundreds of files without the ability to make comprehensive tests of those changes. On general principles, it just feels like a worrisome practice. Specifically...
Do we have a mechanism for protecting against changing the version number where it's not warranted? For example:
If the current link is to 17.01.3 (presumably, because someone manually set it that way), does the script test so that it will not update the link to 17.01.5?
Or if testing shows that 17.01.5rc1 doesn't work for a particular router (but 17.01.4 does), is there a way to indicate that the download link should not be updated automatically when 17.01.5 is released?
Is the knowledge/authorization of how to run the script adequately distributed amongst team members? This isn't just a one-shot process (like importing OpenWrt pages into the new wiki), but it becomes part of the production release process.
Finally, the mass change does obscure Recent Changes. The automatic updates (say, 17.01.3 -> 17.01.4) cause the list of Recent Changes to be filled with hundreds of lines that don't carry much information. (I also wish the "Links changed because of a move operation..." messages could also disappear, but those mass changes (mostly due to OpenWrt imports) will go away after a while.)
re: specific version number vs "stable": We will always face the problem of people saying, "I have the latest/most recent..." (even if they don't). I don't see that this bears on the problem of having a separate name ("stable") that is a symlink/redirect to the currently released version.
I'm not sure if I understand you correctly... Do you mean "comprehensive tests" for the dataentry change from 17.01.3 -> 17.01.4, i.e. if links etc are working, or do you mean "comprehensive tests regarding correct functionality of 17.01.4 on a specific device"?
No. The script simply replaces $support_old by $support_new.
e.g. 17.01.3 -> 17.01.4: Only 17.01.3 dataentries will get updated, nothing else.
If a device is stuck at 17.01.2 (no 17.01.3/4 image available), it will not get updated automatically, but I will check manually if there is a new image available.
Not at all. Updating the dataentries is currently a one-man-show (read: done by tmomas), although I wouldn't mind having this update included in the general "build new release" activities.
My concern is that it's infeasible to test a mass change from one version to the next. (That's more or less the "comprehensive test" I spoke of.) Since we have no access to most of the routers, and potentially they aren't even in service any place on the planet, we'll never know.
I will concede that there's no difference with a "stable" symlink/redirect - we wind up in exactly the same state.
The solution for either of these is for people who own that router to update the page to point to the last-working version.
Actually, you've answered my question - "Yes, we do have that protection." The script won't update a link if it's not exactly the right version. So a device that's stuck at 17.01.2 will never be updated automatically.
I agree this should become part of the standard release process. I will leave the implementation decision to people more familiar with that machinery.
Ahah! You can suppress those? Great!
I still remain uneasy changing hundreds of files automatically, but I cannot come up with a plausible failure mode that would argue against this. I consider this Solved, and updated the OP to reflect this. We can go work on more important things. Thanks.