Release 0.4 proposal

[Deedasmi]

I'd like to propose that 0.4 be a 'You're welcome to make your own plugins' semi-stable release. Here is a shortlist of items that need to be addressed first:

• Document agent_lib, receptor_lib, and shared_lib
• Create a 'plugin creation guide' outlining all plugin requirements
• Decide on a naming convention
• Publish agent_lib, receptor_lib, and shared_lib to crates.io
  • Switch plugins from using path-dependent dependencies to crates dependencies
• Possibly pull plugins out to a separate repo.
• Start following semvar

Other notes

1. I still want to work on Refactor receptor plugins #6, at least get it proofed out, which would be a breaking change.
2. I don't think Plugin configuration #5 or Agent/Receptor Authentication #7 will be breaking changes.

[George3d6]

Seems reasonable, feel free to create the realease (or I will do soon soon[tm]).

Don't you think it might be a bit Overkill publishing all plugins and making them separate crates/projects though ?

Would it bring any real adavantage ? It seems like hell Dev wise and changing the relatively few agent plugins is already annoying.

[Deedasmi]

To clarify, I would probably only suggest one 'inquisitor_plugins' repo, not individual repos for all plugins. That would be a pain. Basic structure would probably be:

README.md
Cargo.toml // Authors, workspace
LICENSE.md  // Might want in individual plugin repos? Not sure
agent_plugins/
  alive
  command_runner
  ...
receptor_plugins/
  sync_check
  ...

Having the plugins out in a different repo allows us to keep the commit and release history in this repo clean. You can still use git links in cargo for unpublished crates, which is what I would suggest initially. See note at end of post.

The situation I specifically want to avoid is release tag 1.0 being 120 commits behind master, none of which actually affect the 'core' of the agent/receptor. Or maybe they do. Hard to tell. Change log would be a pain of scrolling through dozens of plugin only commits. It also has the benefit of having a separate issue tracker for plugins.

Initially, using git links for the actual plugins in the Cargo.toml should be fine. However, before 1.0, we should publish them so that individuals can 'lock' their plugin to a certain version. The big use case for publishing individual plugins is if you're running some type of metrics or report on the data. Having agents dispersed over multiple versions can change what data is stored and break the reports.

[George3d6]

One repo for all the "core" plugin seems much more reasonable to maintain.

I will also be merging the agent_lib, receptor_lib and shared_lib tomorrow, into a big "inquisitor_lib" to be used by plugins.

However, can we use git links in the Cargo.toml for individual plugins if they are all in the same repo ? E.g. something like: github/Inquisitor/agent_plugins/file_checker ? Or would be have to include all plugins in bulk and just activate the ones we need (whilst we go with the shared repo approach and don't publish them on crates) ?

[George3d6]

Also, if we are going to separate this into 2 or 3 repos, I think it may be worth looking into the github "project" feature thing, personally I've never used it.

[Deedasmi]

Honestly, I can't promise, that is an assumption I made. I'm entirely offline this weekend, but will test it out when I get back if you haven't gotten to it.

Do you mean organizations? They are useful and pretty easy to use.

[George3d6]

I feel organization may be too large in scale for this project at the moment, to be honest. For now I'd be tempted to keep it together and if we get some traction (e.g. at least 3-4 contributors and 5-10 active users or at least users that are prototyping this in their test infrastructure) we could think about splitting up the code.

... but those are just my feeling for the moment, that is, that I'd prefer to delay the splitting up of the project on github for a while.

[Deedasmi]

Sounds good. I'm closing this in favor of #49, #48, #40, #39, and #15