You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We have CI to run the test suite with an older nix-daemon, but not the other way around.
We should test changes to the daemon with an older client.
Describe the solution you'd like
Testing with an older client would be very annoying if we had to add conditionals about the client version in the test suite.
Instead, for master CI, we could run old test suites from the -maintenance branches, and insert our new daemon into it.
This increases the maintenance burden slightly, as changes to the test infrastructure may need to be backported, but this is only occasionally needed, and the added assurance outweighs the time investment. It probably pays off in development effectiveness, as manual testing won't be needed, and mistakes are found sooner.
On the -maintenance branches, we can actually refer to "future" daemon implementations as well, and we should do it. This makes those test infra backports easier, and it could catch mistakes in backports.
Describe alternatives you've considered
Add conditionals on the client version in the test suite, just like we do with the daemon. We had some code that seemed to want to try this, but was never completed. That was removed in #11800. As mentioned, the conditionals would have been very annoying (if not infeasible).
Is your feature request related to a problem? Please describe.
We have CI to run the test suite with an older nix-daemon, but not the other way around.
We should test changes to the daemon with an older client.
Describe the solution you'd like
Testing with an older client would be very annoying if we had to add conditionals about the client version in the test suite.
Instead, for
master
CI, we could run old test suites from the-maintenance
branches, and insert our new daemon into it.This increases the maintenance burden slightly, as changes to the test infrastructure may need to be backported, but this is only occasionally needed, and the added assurance outweighs the time investment. It probably pays off in development effectiveness, as manual testing won't be needed, and mistakes are found sooner.
On the
-maintenance
branches, we can actually refer to "future" daemon implementations as well, and we should do it. This makes those test infra backports easier, and it could catch mistakes in backports.Describe alternatives you've considered
Add conditionals on the client version in the test suite, just like we do with the daemon. We had some code that seemed to want to try this, but was never completed. That was removed in #11800. As mentioned, the conditionals would have been very annoying (if not infeasible).
Additional context
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: