Matt, that is a good observation and meanwhile with pulp2 we had such a policy, we cannot adopt it with pulp3. Release fast and release often is something we are trying to stick to.
It would be best to agree on the LTS version that would make all the stakeholders happy but as it was pointed out not sure how we'd make this possible, everyone has a different pace and release cycle. Having that said, we should probably stick to option1 which puts more burden on us but in return users and stakeholders are happy and the project's upgrade path is stable. One thing we could possibly do about the backport requests is to really be thorough about which ones to accept by assessing the impact of the stakeholder who has created the request and their possibility to upgrade if any. -------- 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 Wed, Jan 6, 2021 at 2:18 PM Matt Pusateri <mpusa...@redhat.com> wrote: > Another option is Current Version minus X (N-1, N-2, etc.) If for instance > you say we support N-1, and current version is 3.9, then you'll back port > to latest 3.8.x. N-2 at current version 3.9, would backport to 3.8.x, > 3.7.x, etc. The advantages here are that you already set the expectation > for everyone, you limit the versions you support, you force people to stay > current to get fixes. The downside is that people have to upgrade and or > it could impact downstream schedules. The impact with going this route is > affected by the release velocity. So if you're rapidly releasing major > versions, then it's more likely people won't keep up, or that they'll have > to upgrade and are not able to for some reason. > > Matt P. > > > On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg <mdell...@redhat.com> > wrote: > >> Thanks for putting all the options together. >> I would say that option 2 is a recipe for very bad user experience, and >> i'd vote strongly against it. >> I am ok with option 1, but I would add that the backport to the >> intermediate minor releases _must_ be performed (as in released) counting >> down, to always meet that upgrade expectation. Remember releasing can be >> delayed unexpectedly due to reasons. >> If we go for option 3, I think it's advisable to try to sync up >> stakeholders, because we don't want to maintain consecutive minor versions >> as LTS, and again, backporting a fix must traverse all maintained LTS in >> backward order. We should add expectations to how long we can keep an LTS >> version alive, and how often we bless one. >> >> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko <ttere...@redhat.com> >> wrote: >> >>> 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 >>> >> _______________________________________________ >> 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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
