As an action plugin author, I have a couple of questions what is the recommended/smart way of publishing plugins within official PCM infrastructure. So, I’ll summon @qu1ck to offer his advice. Other opinions are also welcome.
When I update a plugin should I keep the previous versions available within PCM or not? Could there be any issues once PCM gets the proper update logic?
If I have a plugin that is compatible with 6.0.x and I would also like to publish the same plugin compatible with 6.99, but the plugin code differs for each version, what is the best strategy?
Should I move the version handling code inside the plugin? This means a lot of additional if/else statements or method overloading/monkeypatching, which will place a significant burden on plugin maintenance? And I’d really like to avoid this.
Can I have two versions (e.g. major versions) of the plugin where one version is available only to 6.0.x and the other only to 6.99, using the kicad_version and kicad_version_max fields ?
I recommend to keep previous version only if it’s meaningfully different i.e. either is the last one compatible with some specific version of KiCad or has some functionality that was later removed for whatever reason.
There will be no issues with PCM update logic, the case where user has a version of a package that is no longer in the repo will be handled.
That’s what I do for ibom and some other plugin writers do in form of adding a compatibility layer or something like that. I find it’s not that much code and simplicity for the user is worth it (i.e. latest version works with any kicad), however it likely depends on how exactly you use the API.
That said, 6.99 is special case as it doesn’t have stable API. I chose to not publish a package for it at all and direct my users to github to get the tip of master branch if they use nightly.
You can do this but because of unstable API simple version check doesn’t guarantee compatibility, you will always have periods of time where your package is broken.
Yeah, I’ve got a PR on one of my plugins which makes the plugin compatible with 6.99 (and incompatible with 6.0.x) and the author seems willing to keep the plugin compatible with 6.99. So any issue with 6.99 will be up to him to resolve.
I have no issues with packaging the 6.99 version of the plugin and make it available for manual download as .zip file and I was just thinking how to make it available through PCM without causing any confusion for the users. Obviously integrating the version handling code would make things easier from user and publishing point of view. But in this case I’d have to get in on the development and I don’t really want to (especially with 6.99 fluid python API).
So I am going to keep the development for each branch separate, which will complicate things a bit from publishing point of view.
It’s my first time managing such a software configuration (multiple active branches, …) so I learn as I go along. Thanks for the input.