<div dir="ltr">+1 to the plugin -> core dependency. But I can't see ever needing a core -> plugin dependency. <div><br></div><div>Doing so would introduce conflicts when it comes to some dependence resolution, like when</div><div>pulpcore-plugins v0.1.a1 depends on pulpcore v3.0</div><div>pulpcore v3.0 depends on pulpcore-plugins v1.0</div><div><br></div><div>@bmbouter yeah <span style="font-size:12.8px">pulpcore.plugin is where I'm thinking it should be installed. </span></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 3:09 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Jun 1, 2017 at 2:38 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div class="m_-6518117146742756648HOEnZb"><div class="m_-6518117146742756648h5">On Thu, 2017-06-01 at 11:18 -0400, Bihan Zhang wrote:<br>
> I've been documenting the plugin API semver strategy for 3.0 but I've noticed that the plugins<br>
> were recently moved from plugin/pulp/plugin to platform/pulp/plugin<br>
><br>
> My understanding was that we would have separate packages for plugin and platform to enforce the<br>
> separate semantic versioning, instead of just having documentation on the plugin version supported<br>
> by platform. <br>
><br>
> I think the correct workflow is for a plugin writer would denote in their spec file (or setup.py)<br>
> what pulpcore-plugin versions are supported, and on installation the package manager can pull in<br>
> the correct pulpcore-plugin package with the correct platform dependency.<br>
><br>
><br>
> I wanted to check that this was everyone else's understanding too.<br>
<br>
</div></div>+1 to separating these as packages.  Having a package version to depend on should help enforce the<br>
plugin api version.<br></div></div><span class="">______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-6518117146742756648gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>