[Pulp-dev] Pulp3 Plugin API SemVer Strategy

Brian Bouterse bbouters at redhat.com
Thu Jun 1 18:51:02 UTC 2017


+1 to this idea. It's something we talked about before, but we never
actually decided on. This thread I think is just what we needed to do that.
Then a plugin like pulp_foo can depend on pulpcore indirectly through
pulpcore.plugin with pulp_foo -> pulpcore.plugin -> pulpcore.

The PyPI name of pulpcore-plugin sounds right. That will provide the Python
package that installs in: pulpcore.plugin yes?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170601/d778687f/attachment.htm>


More information about the Pulp-dev mailing list