<div dir="ltr">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.<div><br></div><div>The question which hasn't been answered yet (in documented way) is:</div><div><i>Should backports be backported to every (minor) version between the fix and the requested version?<br></i><div><br></div></div><div>E.g. A backport is requested for 3.7, the original fixed will be released in 3.10.</div><div>Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?</div><div>Reminder: a backport can only be a bug fix and without a db migration.</div><div><br></div><div>Option 1. Backport to all releases in between.</div><div> + it's an expected upgrade path for users, no surprises, the fix is present all the way.</div><div> - it's a lot of maintenance and release burden, and the further backport is the worse it is.</div><div><br></div><div>Option 2. Backport to the requested release only.</div><div> + just one backport and release to do</div><div> - 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.</div><div><br></div><div>Option 3. Have LTS releases and allow backports to the latest LTS only</div><div> + just one backport and release to do</div><div> + users are aware that backports go only into this release and do not expect fixes in non-LTS releases in between</div><div> - less flexibility with multiple stakeholders (e.g. Katello will benefit from 3.7 being an LTS release, Galaxy - from 3.8)</div><div><br></div><div>Please share your thoughts or suggest other options,<br></div><div>Tanya</div></div>