With more and further away backport requests coming in, there is more need for a clear policy/docs to set expectations for users and to define requirements for those performing a backport.
The question which hasn't been answered yet (in documented way) is: *Should backports be backported to every (minor) version between the fix and the requested version?* E.g. A backport is requested for 3.7, the original fixed will be released in 3.10. Should the backport be added only to 3.7 or to 3.8 and 3.9 as well? Reminder: a backport can only be a bug fix and without a db migration. Option 1. Backport to all releases in between. + it's an expected upgrade path for users, no surprises, the fix is present all the way. - it's a lot of maintenance and release burden, and the further backport is the worse it is. Option 2. Backport to the requested release only. + just one backport and release to do - inconsistent user experience if a user doesn't upgrade to the latest version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the very least, imo. Option 3. Have LTS releases and allow backports to the latest LTS only + just one backport and release to do + users are aware that backports go only into this release and do not expect fixes in non-LTS releases in between - less flexibility with multiple stakeholders (e.g. Katello will benefit from 3.7 being an LTS release, Galaxy - from 3.8) Please share your thoughts or suggest other options, Tanya
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev