I’m sure this has been talked about, and it sounds like a very ARDUous task (see what i did there?)
I see a lot of people on various versions of AP. And the features, parameters, commands, setup instructions, tend to change as versions change. I proprose that the Wiki needs to support users who are not on the “latest” version, or ARE on the latest version, being able to tell if the content they are reading applies to their version.
Something similar to this from Microsoft. Note: Microsoft used to have a drop down selector which allowed you to change the instructions based on the version of the item you’re looking for.
Like this:
Some of their pages now have something like this instead to indicate which versions the instructions are for: VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
They program this into their sites using .md files. Here is an example.
Anyways, I’ve seen many people switching from 3.5 to 3.6 beta and having troubles with the param changes. AP is already a daunting challenge to learn, which is fine because it is a very advanced autopilot. But confusion due to users not knowing whether the documentation they are looking at is for their version or not makes it worse. I imagine there are some that may stay on a particular version and never upgrade due to re-certification requirements. So the documentation will almost immediately be wrong for them.
Thoughts on how this could be done? Or whether anyone else thinks it is even needed?
The wiki does need a clean up, but finding someone with the knowledge, skills, time and motivation to do it is a huge challenge.
What’s the driver for maintaining documentation for superseded firmware?
In my view the wiki should reflect the latest stable release, and realistically due the the fact that wiki amendments haven’t been tagged to firmware versions, it would be a massive undertaking to retrospectively try to change that for all firmwares and build targets.
From memory we did pull a PDF for the APM boards when we dropped firmware support though.
Re users using older firmware: sure, but there’s nothing preventing them cloning the wiki from the time of the particular firmware release they’re using (it’s in GitHub, as you know).
Maintaining support for all firmware versions is a burden that the project doesn’t have resources for - and users are almost always better off updating.
Just my 2c.
There’s master. There’s betas. There’s releases. There’s prior releases. I don’t see it as being practical to maintain multiple variations. It would be awesome. But it’s just barely got the manpower to keep up as is now.
