[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