I would like to see PRs accepted for each generation

ArduCopter
1

I think the new generation contains a lot of problems.
I think the copters include 3.2.1, 3.4.6, 3.5.7, 3.6.12 and 4.x.x generations I think there is.
I know that ArduPilot is being used for business drones in the country of Japan.
I know that each generation of business drones in Japan is used for business drones in Japan.
Business drones in the hands of consumers in Japan are very difficult to change generations.
Consumers in Japan are happy with the capabilities of each generation.
If a consumer in Japan has a problem with the operation, they would like to change only the problem.
I would like to see each generation accept PR that is specific to the newly discovered problems and their solutions.

2

This is not going to happen and should not. Development resources, which are limited, should be applied to the latest revisions of Ardupilot to advance the code for hardware as it advances.

1 Like
3

That would be cause huge mess and lots of work.

I kind of expect to hear now that you run windows 1.0 , Linux kernel 0.01 and never accept an upgrade from Tesla.

4

Note that nothing stops that business from employing someone to patch the
software they wish to continue to run which the ArduPilot project has
moved on from.

5

I can understand.
Hard to solve for the problems that arise with each generation in a situation where ArduPilot resources are low.

I use the older generation for business drones.
I will be maintaining this older generation.
I am hoping to have a contributor that is using the older generation.
I’m hoping to be able to share information and source review via GitHub for that contributor and ArduPilot.
I think there’s an advantage in being able to share modified sources held by contributors who continue to use older generations.
I think I can implement the PR for problems I will encounter in the future if the fixed source is available.