[Pulp-dev] Pulp3 Plugin API SemVer Strategy

[Bihan Zhang]

+1 to the plugin -> core dependency. But I can't see ever needing a core ->
plugin dependency.

Doing so would introduce conflicts when it comes to some dependence
resolution, like when
pulpcore-plugins v0.1.a1 depends on pulpcore v3.0
pulpcore v3.0 depends on pulpcore-plugins v1.0

@bmbouter yeah pulpcore.plugin is where I'm thinking it should be
installed.



On Thu, Jun 1, 2017 at 3:09 PM, Michael Hrivnak <mhrivnak at redhat.com> wrote:

> 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
>
> _______________________________________________
> 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/20170602/3a79a2a7/attachment.htm>