[Pulp-dev] Pulp3 Plugin API SemVer Strategy

Michael Hrivnak mhrivnak at redhat.com
Thu Jun 1 19:09:03 UTC 2017

I think I brought up this idea rather off-the-cuff in a meeting some weeks
ago, but we never had more formal discussion, so thanks for bringing it
back up! I do think this is a good approach for us to explicitly
communicate the version of our plugin API.

That said, it is a slightly different use case from a normal python
package, and it's worth just thinking through and acknowledging that. The
interesting part is that both the core and the plugin API packages will be
useless without the other. The core is no good to anyone without plugins.
And the plugin API obviously can't be used without the core. That's often a
sign that two things should be distributed together, but we have one extra
and separate reason to package them independently: we want their versions
to move independently. I think that's reason enough for separate packages.

In terms of package dependencies, maybe we should start with the plugin
package depending on core, but not the other way around. The core won't
care what version the plugin API is at, but the plugin API will definitely
care what version the core is at. If we later find a reason to make the
core package directly depend on the plugin API, it's easy to add.

On Thu, Jun 1, 2017 at 2:38 PM, Patrick Creech <pcreech at redhat.com> wrote:

> On Thu, 2017-06-01 at 11:18 -0400, Bihan Zhang wrote:
> > I've been documenting the plugin API semver strategy for 3.0 but I've
> noticed that the plugins
> > were recently moved from plugin/pulp/plugin to platform/pulp/plugin
> >
> > My understanding was that we would have separate packages for plugin and
> platform to enforce the
> > separate semantic versioning, instead of just having documentation on
> the plugin version supported
> > by platform.
> >
> > I think the correct workflow is for a plugin writer would denote in
> their spec file (or setup.py)
> > what pulpcore-plugin versions are supported, and on installation the
> package manager can pull in
> > the correct pulpcore-plugin package with the correct platform dependency.
> >
> >
> > I wanted to check that this was everyone else's understanding too.
> +1 to separating these as packages.  Having a package version to depend on
> should help enforce the
> plugin api version.
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev


Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170601/b1c8bd1e/attachment.htm>

More information about the Pulp-dev mailing list