Npgsql: Plugin repo and versioning strategy

[roji]

Our Npgsql plugins (NetTopologySuite, NodaTime...) are currently hosted inside the main Npgsql repo. This is problematic for versioning/release reasons - we don't want to artificially bump plugin versions every time we release a version of Npgsql, but versions are managed on a repo-wide basis (I'm referring to version tags, github milestones, etc. etc.).

I think it's time to split each plugin off to its own repo, allowing each plugin to have its own clean, separate lifecycle. This also means that users will have to open issues on those repos instead of here (otherwise we can't milestone them), which will probably be a bit confusing.

What do you think? This is relevant also for the EF Core plugins.

/cc @YohDeadfall @austindrenski @Brar @rwasef1830

PS I made a silly mistake... When first releasing the plugins, the Npgsql plugins are properly versioned 1.0.0, 1.0.1 etc. However, the EF Core plugin are unfortunately versioned 2.1.0, 2.1.1 as if they're following the main release. It's too late to change this, so we'll probably have to stick to that going forward.

[austindrenski]

I think it's time to split each plugin off to its own repo, allowing each plugin to have its own clean, separate lifecycle. This also means that users will have to open issues on those repos instead of here (otherwise we can't milestone them), which will probably be a bit confusing.

What do you think? This is relevant also for the EF Core plugins.

Would the plugins for the driver and provider share repos? Or would those stay separate too?

Only thought on keeping driver/provider plugins separate is that we have +2 repos for every new plugin, but that isn't necessarily a bad thing.

PS I made a silly mistake... When first releasing the plugins, the Npgsql plugins are properly versioned 1.0.0, 1.0.1 etc. However, the EF Core plugin are unfortunately versioned 2.1.0, 2.1.1 as if they're following the main release. It's too late to change this, so we'll probably have to stick to that going forward.

FWIW this seems to follow the ASP.NET Core/EF Core style of package releases, which seems to be helpful for consumers.

[roji]

Would the plugins for the driver and provider share repos? Or would those stay separate too?

That's a good question. Any release of the Npgsql plugin should also be accompanied by a release of the EF Core plugin (since the dependency should be updated), but the opposite isn't true - we may fix a bug in the EF Core provider and release a version, without that having anything to do with the Npgsql plugin. A good example is your current work on translating NodaTime's SystemClock.Instance.GetCurrentInstant() (https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/issues/502). So I'd vote for two separate repos there as well.

Yeah, it's a lot of repos, but the only actual downside to that seems to be user confusion around where to submit issues. I'm not saying that's not an important factor, but it doesn't seem enough to block this.

PS I made a silly mistake... When first releasing the plugins, the Npgsql plugins are properly versioned 1.0.0, 1.0.1 etc. However, the EF Core plugin are unfortunately versioned 2.1.0, 2.1.1 as if they're following the main release. It's too late to change this, so we'll probably have to stick to that going forward.

FWIW this seems to follow the ASP.NET Core/EF Core style of package releases, which seems to be helpful for consumers.

I guess it depends to what extent compatibility is broken between minor/major versions. If a minor (or major) version upgrade of Npgsql typically requires you to also upgrade all the plugins, then it makes a lot of sense to track the versions, otherwise less so. If we feel that it makes sense, we can also bump the Npgsql plugins to 4.0 to align.

[roji]

To continue this discussion, this also has to do with our versioning strategy for plugins (see discussion in #2162).

Contrary to what I wrote before (I've been going back and forth in my head...), I'm currently leaning towards actually keeping everything in the same repo, and having plugins follow the same major/minor versions (but not patch) as the main project. So Npgsql.NodaTime would be versioned 4.0.x, being compatible with Npgsql 4.0.x. Once we release Npgsql 4.1.0, we would also release Npgsql.NodaTime 4.1.0. This would make it easier for consumers to know what works with what, and also (realistically) assumes that there are some breaking changes in the API between Npgsql and its plugins when major/minor versions are released.

If we do this, it also seems to make sense to keep everything in the same repo, as release schedules are (at least partially) connected...

[Brar]

I totally agree!
We surely want to avoid the question which plugin version works with which version of Npgsql.
The simple answer is: just keep Npgsql and Plugin versions in sync.
In that case it is ways less maintenance work if we keep everything together in one repo.

[roji]

So I think we all agree on this: plugins will track Npgsql's major and minor versions (but not necessary patch versions), and will continue to live in the same repo. If anyone has any further suggestions or ideas please post back here.