On Tue, 2018-06-19 at 11:06 -0400, Dennis Kliban wrote: > On Tue, Jun 19, 2018 at 10:54 AM, Ina Panova <[email protected]> wrote: > > 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. >
So, I've done some looking into this to see if there are viable strategies to do this, and there does appear to be so. Currently, there does appear to be feasible ways to ensure this. that shoudln't be too much trouble to implement in time for 2.17. From a build team standpoint, whatever the pulp team decides to do here, there are routes for build infrastructure to support it. ------- One thing I want to mention here is, the use case of updated to latest then downgrading. Pulp's database migrations are written to be one way idempotent. From my time on the team, I don't recall a way to 'undo' a migration after it has been ran. I do not think pulp is capable of 'downgrading' a plugin to an older version at this time, users would need to restore from backups. This will probably play a factor from time to time. Based on the conversations I've heard so far, the main worry is that if something is broken in a plugin from a x.y.z to a x.y+1.0 we want people to be able to revert back to x.y.z. Semantic versioning, iirc, states that things should not break from an x.y.z to an x.y+1.0. Pulp has blocked releases and hotfixed for things like this before. For sake of argument, the semantic version comparison is scoped purely to the plugin version, not overall 'platform' version. My personal opinion here is that some more thought/discussion should probably be had around what these last two concepts mean to updating .y version plugins in a pulp .z stream update. Build team will make the changes on our end to help support whatever this decision ends up being.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
