That sounds good to me. What if for the GA, we just not create a new version if content hasn't changed and then create an issue for post-GA to add a setting to always create a new version?
David On Tue, Nov 5, 2019 at 3:28 AM Fabricio Aguiar <fabricio.agu...@redhat.com> wrote: > how about making a default setting and document, adverting why the default > is (bump/not bump the version). > This way we give autonomy to users to decide whether to bump or not the > version > > Best regards, > Fabricio Aguiar > Software Engineer, Pulp Project > Red Hat Brazil - Latam <https://www.redhat.com/> > +55 11 999652368 > > > On Mon, Nov 4, 2019 at 10:52 PM Mike DePaulo <mikedep...@redhat.com> > wrote: > >> >> >> On Mon, Nov 4, 2019 at 4:50 PM Mike DePaulo <mikedep...@redhat.com> >> wrote: >> >>> >>> >>> On Mon, Nov 4, 2019 at 4:39 PM Brian Bouterse <bmbou...@redhat.com> >>> wrote: >>> >>>> tl;dr I'm +1 to making this switch. >>>> >>>> On Mon, Nov 4, 2019 at 3:51 PM David Davis <davidda...@redhat.com> >>>> wrote: >>>> >>>>> Currently in pulp, syncs always create repository versions regardless >>>>> of whether or not any content changed. One of the tasks[0] for 3.0 GA is >>>>> to >>>>> document this behavior. However, I've heard several complaints about this >>>>> from users so I wonder if it's worth reconsidering. >>>>> >>>> I love making users happy, but the complaints didn't resonate as much >>>> with me because another user with a different subjective preferences could >>>> walk up and complain after we switch it. I try to listen for user >>>> complaints that come with objective claims of usability. >>>> >>>> >>>>> Here are some reasons against always creating repo versions: >>>>> - They were meant to serve as a historical record but this information >>>>> is available by looking at the tasks api >>>>> - It creates additional, unnecessary versions and bumps the latest >>>>> version number of the repo >>>>> - If we ever have a feature to retain only the latest X repo versions, >>>>> it'll be less useful since some repo versions may not have any changes >>>>> >>>> This last bullet I see an objective reason to make no-content-change >>>> repo versions not increment. Users concerned about their cron jobs not >>>> running can check the task records. Users get RepositoryVersions that >>>> always include change and are therefore more meaningful (perhaps that was >>>> Bin Li's objective claim). Also future users could get a repo-version >>>> retention option which would be difficult to create if we don't switch >>>> this. >>>> >>> >>> From a black-box perspective, how about some sort of compromise >>> solution? Like a minor version number being bumped if there is a no-change >>> sync. Or a separate field like "1st identical repo version." >>> >> >> Whether we implement a compromise or not, this current proposal should be >> implemented 1st. >> >> +1 >> >> >>> >>> >>>> >>>> >>>>> Any thoughts? I'd like to get this on the sprint by Wednesday so it >>>>> can be changed before the dev freeze date of Nov 12. >>>>> >>>> +1 to making this change >>>> >>>>> >>>>> [0] https://pulp.plan.io/issues/3308 >>>>> >>>>> David >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> >>> Mike DePaulo >>> >>> He / Him / His >>> >>> Service Reliability Engineer, Pulp >>> >>> Red Hat <https://www.redhat.com/> >>> >>> IM: mikedep333 >>> >>> GPG: 51745404 >>> <https://www.redhat.com/> >>> >> >> >> -- >> >> Mike DePaulo >> >> He / Him / His >> >> Service Reliability Engineer, Pulp >> >> Red Hat <https://www.redhat.com/> >> >> IM: mikedep333 >> >> GPG: 51745404 >> <https://www.redhat.com/> >> _______________________________________________ >> 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