Governance/maintenance of plugins/extensions about protoactor-dotnet HOT 11 CLOSED

100% agree on this.
Let's keep the core API surface area as small as possible, but with a lot of extension points.

regarding the different ways to set things up, I believe that 1) would be the most successful initially.
This would show the community that we do have many plugins. to build traction around Proto.Actor.

That being said, in the long run, I do think that it would make sense to move more towards 2).
When trust and momentum have already been established.

from protoactor-dotnet.

Personally I'd prefer to see option 2 as I think it will help when writing integration tests for the persistence plugins. I couldn't find any tests around them so far, but imagine checking out an "extensions" repo and then having to install all databases supported to get integration tests to pass (I'm presuming not all have in-memory versions to test against). If they are separate, you only need the one you're interested in.

from protoactor-dotnet.

3. Move each extension into a separate repo INSIDE of the organization? :)

from protoactor-dotnet.

My only current issue is that builds aren't quickly being done while the API and stuff is still churning a lot as it's early days. This is why I'd prefer in the same repo for now.

I think having some "blessed" extensions in option 3 and some "extended" extensions for option 2 is good.

from protoactor-dotnet.

Sorry just re-read the description of no. 2 and I thought it was what @raskolnikoov has proposed as 3. :)

So my vote would go for 3. (i.e. separate repos inside the organisation) and for me reading things more carefully

from protoactor-dotnet.

How about something like

protoactor-dotnet - core libraries (Actor, Mailbox, Cluster, Persistence, Remote and Router)
protoactor-dotnet-contrib - includes things like strongly typed actors, patterns like process managers etc
protoactor-dotnet-couchdb
protoactor-dotnet-mongodb
protoactor-dotnet-marten
protoactor-dotnet-ravendb
protoactor-dotnet-eventstore
...etc, all within AsynkronIT? Or create a ProtoActor organisation?

Should allow core library to develop and give an area (contrib) for people to add magic on top :)
Separate repo's per persistence providers would allow integration tests to be written without everyone having to install all supported databases - they would each get their own build pipelines, maintainers etc..

from protoactor-dotnet.

I like @tomliversidge 's ideas around the repos. Something to think about to how to manage code and updates and common files (e.g. gitignores) across repos. It's not really a problem I've solved :)

from protoactor-dotnet.

Yeah, I like that structure too :)

@adamhathcock For gitignore cp works just fine for me ;) For e.g. build scripts, we could use a Git submodule.

from protoactor-dotnet.

So who takes the first step :)

from protoactor-dotnet.

I'm a fan of 1 for now moving toward 3 as the project matures. I think that will make it simpler for new contributors at this early stage.

from protoactor-dotnet.

Ref #499

from protoactor-dotnet.