I think removing APIVERSION is a good thing and that we should adhere
to semantic versioning (https://semver.org/). The guarantee for semver
is that the major version increases when backwards compatibility is
broken. Plugin handling should follow and everything that builds for 7
(any version) should go in one folder. If there's a specific minor
version requirement, we can handle that at load time of the plugin.

That said, I think maybe the thing we need is to remove the current
strange moduleInfo reporting of single number made up of major, minor,
patch, and require returning a version info struct or int array.
That'd make it clearer IMO for what version an opcode was compiled for
and aid checking of version requirements.

On Wed, Nov 6, 2024 at 12:04 PM Eduardo Moguillansky
 wrote:
>
> Hi,
>
> in csound 6 APIVERSION was set to 6.0 independently of the version of csound. APIVERSION is used, among other things, to determine the installation path of plugins. This has changed in csound 7, where APIVERSION follows the major and minor version of csound and forces a plugin installation folder for each minor version. While this might make it possible for multiple versions of  csound 7 to coexist (which is good) it makes it unclear what the policy is regarding installation paths and compatibility.
>
> My suggestion would be to disentangle csound version and api version, and maybe sync those to whenever there are actual changes to the api. By linking those too closely, as it is right now, we lose some nice aspects of the plugin design, among others upward compatibility.
>
> cheers
> Eduardo

Ah, we should just change that to
${LIBRARY_INSTALL_DIR}/csound/plugins64-${CS_MAJOR}" IMO. Should tick
off all the boxes and be in sync for semver guarantees.

On Wed, Nov 6, 2024 at 4:54 PM Eduardo Moguillansky
 wrote:
>
> My question is somewhat more pragmatic: at the moment csound sets the plugin dir as "${LIBRARY_INSTALL_DIR}/csound/plugins64-${APIVERSION}". Since APIVERSION is set to ${CS_MAJOR}.${CS_MINOR} plugins are installed to/searched from a folder specific to the csound version. When installing csound plugins we would then need to check the csound version, check for which version the plugins were built and determine if these versions are compatible, etc. I wouldn't advocate for removing APIVERSION but from removing the parallelism with the csound version, since they indicate two different things.
>
> On Wed, Nov 6, 2024 at 7:10 PM Steven Yi  wrote:
>>
>> I think removing APIVERSION is a good thing and that we should adhere
>> to semantic versioning (https://semver.org/). The guarantee for semver
>> is that the major version increases when backwards compatibility is
>> broken. Plugin handling should follow and everything that builds for 7
>> (any version) should go in one folder. If there's a specific minor
>> version requirement, we can handle that at load time of the plugin.
>>
>> That said, I think maybe the thing we need is to remove the current
>> strange moduleInfo reporting of single number made up of major, minor,
>> patch, and require returning a version info struct or int array.
>> That'd make it clearer IMO for what version an opcode was compiled for
>> and aid checking of version requirements.
>>
>> On Wed, Nov 6, 2024 at 12:04 PM Eduardo Moguillansky
>>  wrote:
>> >
>> > Hi,
>> >
>> > in csound 6 APIVERSION was set to 6.0 independently of the version of csound. APIVERSION is used, among other things, to determine the installation path of plugins. This has changed in csound 7, where APIVERSION follows the major and minor version of csound and forces a plugin installation folder for each minor version. While this might make it possible for multiple versions of  csound 7 to coexist (which is good) it makes it unclear what the policy is regarding installation paths and compatibility.
>> >
>> > My suggestion would be to disentangle csound version and api version, and maybe sync those to whenever there are actual changes to the api. By linking those too closely, as it is right now, we lose some nice aspects of the plugin design, among others upward compatibility.
>> >
>> > cheers
>> > Eduardo