George3d6 / Inquisitor

An easily extensible, minimal footprint monitoring tool. (Still in the testing phase)
BSD 2-Clause "Simplified" License
30 stars 4 forks source link

Semvar convention for plugin authors #40

Open Deedasmi opened 6 years ago

Deedasmi commented 6 years ago

Semvar is reasonably clear, but we should explicitly define what we expect from plugins.

Recommendation:

George3d6 commented 6 years ago

Before the stable release I think the convention will be: -> Major version should match receptor/agent -> Minor version should also match receptor/agent (since we could make API changes in minor version) -> Patch versions are allowed to be different

After the stable release I would agree with the convention you outlined.

At leas those would be my initial thought on the subject.

Deedasmi commented 6 years ago

I see the reasoning, but I feel like it limits authors too much. Especially if someone decides to write a joint client/server plugin to accomplish a specific task before 1.0. It makes the logic of supporting multiple agent versions for the server plugin a mess.

I'd be fine if we followed this convention, but if I was reading a convention guide that suggested I use a patch version for bug fixes and breaking internal API changes I'd probably just ignore it.

George3d6 commented 6 years ago

Hmh... I'm not sure I understand your point here.

If someone decides to write a plugin that's for both the receptor and the agent (E.g. collector piece and processor piece for a specific check), they'd just have to match their minor version to the version of the agent/receptor they are using, how does that limit the author ? And, assuming we can make API changes to the plugin interface in minor versions, how is that not required ?