The structure of this crate was up for discussion right from the beginning (see #1) and we tentatively chose a semantic structure with modules named after their purpose (transport, channel_request, jit_channel).
However, given that the specifications now follow a "no versioning" model in which breaking changes will result in a new LSPSX standard this structure doesn't really make sense anymore. In particular when LSPS4 will become a reality it live side-by-side with LSPS2, so we will have two jit_channel standards for a while.
To this end, we rename the modules accordingly and cfg-gate LSPS1 for now as it's not usable yet, although now checked in CI to make sure we won't break compatibility with it.
Fixes #34
The structure of this crate was up for discussion right from the beginning (see #1) and we tentatively chose a semantic structure with modules named after their purpose (
transport,channel_request,jit_channel).However, given that the specifications now follow a "no versioning" model in which breaking changes will result in a new LSPSX standard this structure doesn't really make sense anymore. In particular when LSPS4 will become a reality it live side-by-side with LSPS2, so we will have two
jit_channelstandards for a while.To this end, we rename the modules accordingly and
cfg-gate LSPS1 for now as it's not usable yet, although now checked in CI to make sure we won't break compatibility with it.