[Pulp-dev] Backports and LTS

Tanya Tereshchenko ttereshc at redhat.com
Tue Jan 5 17:34:22 UTC 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20210105/8322f1e6/attachment.htm>


More information about the Pulp-dev mailing list