Warning: This question may be open ended, but I just wasn't sure if I should post on discourse or not.

I start with describing what I want to achieve.

Situation and problem

• My team came up with a desire for down-most packages to be rebuilt and/or released as rarely as possible, while the upstream packages keep adding changes in the implementation of ROS Service servers the downstream pkgs call.
• Although the .srv files are changing, the core elements are expected to remain the same.

To visualize,

Pseudo format of, say, Upstream.srv in the upstream BEFORE the change.

uint8 input_core_a=0
uint8 input_core_b=1
----
uint8 output_core_a=0
uint8 output_core_b=1

Format AFTER some the change in the upstream.

uint8 input_core_a=0
uint8 input_core_b=1
uint8 input_c=2
----
uint8 output_core_a=0
uint8 output_core_b=1
uint8 output_c=2

As the name of elements hopefully implies, {in, out}put_c are not essential to the downstream nodes and they keep changing, but those with core are essential for the downstream and aren't expected to change. Downstream only want to pass and receive those, and we don't want downstream pkgs to be rebuilt AFTER the changes made.

Potential solution

Option-1. Relaying service

We're leaning toward making a "relay" service node. It 1) gets called by the Service client from down-most pkg/node, 2) calls the service of the upstream pkg/node, then 3) return the service response. Downside is maintenance happens every time the .srv format changes.

Pseudo format of Relaying.srv

For the concrete example above, we can make another .srv type in a relay pkg with the following elements, which contain only those elements with "core" in the name:

uint8 input_core_a=0
uint8 input_core_b=1
----
uint8 output_core_a=0
uint8 output_core_b=1

Option-1-b. Generalizing intermediate/relaying service

Can we generalize the relaying portion, similar to relay_field feature of topic_tools?

Is this a good option? Downsides? Are there better options?