To follow up on this, during the open floor it has been decided to create a Backport tracker to facilitate backport requests, in addition some docs are being written so people have guidelines.
-------- Regards, Ina Panova Senior 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 Thu, Jul 30, 2020 at 7:10 PM Brian Bouterse <bmbou...@redhat.com> wrote: > Currently my understanding of the z-stream policy is that Pulp only has > one active z-stream. This means (for example) that when 3.6.0 comes out, > there will never be another z-stream release for 3.5.z, 3.4.z, 3.3.z, etc. > > I believe we have an opportunity to create more value by adjusting this to > allow for older z-stream releases to be requested as-needed. This would > allow for example Katello's use of pulpcore 3.4.1 to request a 3.4.2 to be > created even if 3.6.0 is released. Similarly for any plugin. These could > only contain bugfixes (never features) due to semantic versioning > restriction. > > This is based on feedback I've gotten from various users including > Katello, and this would allow them to use a version of pulpcore or a plugin > and receive stability fixes without being forced to upgrade. Then they can > upgrade when is right for them (not for us). > > If others agree with this change I think we need to figure out the > following: > > * How can a user request a backport? [bmbouter suggests using a new > tracker type in Redmine named 'Backport'] > * How can mini-teams perform backporting? [bmbouter suggests manual > cherry-picking and releasing as-needed, only with requested items] > > What do you think? > > Thanks! > Brian > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
