tl;dr: you should only receive backwards compatible changes with this approach.
It's a good question to ask. The plugins the core team maintains adhere to semver so these Y updates to plugins will always be 100% backwards compatible. We won't be upgrading a plugin's X release in a single repo, e.g. core's 2.16 repo [0], because that could be backwards incompatible interface for that plugin. [0]: https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server/x86_64/ On Tue, Jun 19, 2018 at 5:53 PM, Tom McKay <[email protected]> wrote: > Just curious, but I assume that for an async plugin release that would > imply zero changes to the exposed APIs and only fixes to the underlying > code? > > As a consumer of pulp, we install pulp-server not individual plugins. If a > plugin changes it's exposed interface (ie. API) then I'd expect a bump on > the primary product version. > > Foreman has an interface layer that, if the API changes, may itself > require updates. If API is 100% backward compatible, then there shouldn't > be a problem. > > On Tue, Jun 19, 2018 at 11:06 AM, Dennis Kliban <[email protected]> > wrote: > >> On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova <[email protected]> wrote: >> >>> Dennis, >>> thank you for sending out the summary of our meeting. >>> >>> Just to highlight and check the overall understanding - there will be >>> one repository per Y pulp release which might contain multiple Z and Y >>> plugin version releases. >>> Correct me if i am wrong. >>> >>> >> That is correct. >> >> >> >>> What would be our next steps in terms of collaboration with the build >>> team? >>> >>> >>> >> My understanding was that Patrick is planning to do some investigation >> and report back on this thread. Please correct me if I am wrong. >> >> >>> >>> -------- >>> Regards, >>> >>> Ina Panova >>> Software Engineer| Pulp| Red Hat Inc. >>> >>> "Do not go where the path may lead, >>> go instead where there is no path and leave a trail." >>> >>> On Mon, Jun 18, 2018 at 8:20 PM, Dennis Kliban <[email protected]> >>> wrote: >>> >>>> Earlier today a few of us met to discuss how we can release new Y >>>> releases of plugins without a Y release of the platform accompanying them. >>>> >>>> The initial proposal was to publish a new Y release of a plugin at the >>>> same time as a Z release of platform and other plugins. More concretely, we >>>> were discussing putting pulp-docker-* 3.2.0 packages into the 2.16 >>>> repository[0]. This repository currently contains 3.1.3 packages. >>>> Publishing 3.2.0 packages to this repository would completely remove the >>>> 3.1.3 pulp-docker packages. Since 3.1.3 pulp-docker-* packages were only >>>> published to the 2.16 repository, the only 3.1.z package available after a >>>> publish of 3.2.0 would be 3.1.2 in the 2.15 repository[1]. After >>>> identifying this problem, we decided to NOT release pulp-docker-* 3.2.0 >>>> with the 2.16.2 z-stream release. >>>> >>>> In order to eliminate this problem in the future, we would like to >>>> investigate if it will be possible to compose repositories with new Y >>>> releases of plugins while retaining the previous versions of packages that >>>> were already published to the repository before. If this is possible, we >>>> would try to start composing our Z stream repositories in such a way >>>> starting with 2.17.0 release. >>>> >>>> Questions? Thoughts? Ideas? >>>> >>>> >>>> [0] https://repos.fedorapeople.org/pulp/pulp/stable/2.16/7Server >>>> /x86_64/ >>>> [1] https://repos.fedorapeople.org/pulp/pulp/stable/2.15/7Server >>>> /x86_64/ >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
